======================================================================== 1 ===
Date:    2 Jan 92 15:10:26 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: Modula-3 News #2 appears

Happy new year! 

Issue 2 of the newsletter "Modula-3 News" was sent out to subscribers
on Tuesday (12/31). It will arrive after normal First Class (foreign
Airmail) delays, plus any holiday delay.

The main topic is "Modula-3 in Academia," with feature articles on
the Univ. of Cambridge, Univ. of New South Wales, and Queen Mary & Westfield
College.

It is interesting that Cambridge, which has adopted Modula-3 as its
main imperative language in the Computer Science course, is where Maurice
Wilkes built the first practical electronic stored-program computer in 1949.
47 years later, Wilkes proposed what became the Modula-3 language 
definition effort.

The newsletter is free. An electronic copy will be posted in a week 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.


======================================================================== 2 ===
Date:    2 Jan 92 15:12:17 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: Re: Modula-3 News #2 appears

Well, perhaps 37 years later...


======================================================================== 3 ===
Date:    Thu, 2 Jan 92 14:30:50 PST
From:    muller@src.dec.com (Eric Muller)
Subject: Modula-3 Frequently Asked Questions (FAQ)

Archive-name: Modula-3-faq
Last-modified: Fri Nov  1 1991


			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.



======================================================================== 4 ===
Date:    Thu, 2 Jan 92 13:51:20 PST
From:    muller@src.dec.com (Eric Muller)
Subject: archive of comp.lang.modula3 for December 1991

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

	gatekeeper.dec.com:pub/DEC/Modula-3/comp.lang.modula3/91-12.Z

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

Happy New Year !
Eric.


======================================================================== 5 ===
Date:    Fri, 3 Jan 1992 12:44:23 -0600
From:    Paul Pomes - UofIllinois CSO <Paul-Pomes@uiuc.edu>
Subject: Re: Modula-3 Frequently Asked Questions (FAQ)

Is anyone working on a Sequent Symmetry with Dynix (not ptx) port?  If
not, what are the tasks involved if I want to do it myself?  Thanks.

/pbp


======================================================================== 6 ===
Date:    3 Jan 92 20:42:26 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: FTP access to Pine Creek available

I am pleased to announce that Pine Creek Software is now permitting
anonymous FTP access to its vast computing facilities and extensive
archives of Modula-3 related information.

	[Translation: I have a couple of things you might like, but if
	more than one person tries to access it at the same time my
	workstation may catch fire.]

Site:      bert.pinecreek.com. 
Login:     anonymous
Password:  your name and host.
Directory: the interesting stuff is in the 'pub' subdirectory of the root

Here is what's available so you won't be in suspense.

pub/BIBLIO                     Modula-3 books and articles
pub/CHANGES                    change history for all directories
pub/FTP                        instructions for using ftp
pub/INDEX                      Index to stuff at this site (see below)
pub/NEWSFLASH                  What's happening when
pub/ORDERS                     Ordering T-shirts and sweatshirts
pub/README                     General organization of the directories

pub/m3news/README              what's in this directory
pub/m3news/m3news1.txt         Issue 1 of Modula-3 News (text)
pub/m3news/m3news1.ps.Z        Issue 1 of Modula-3 News (PostScript(tm))
pub/m3news/m3news2.txt         Issue 2 of Modula-3 News (text)
pub/m3news/m3news2.ps.Z        Issue 2 of Modula-3 News (PostScript)

pub/doc/README                 what's in this directory
pub/doc/m3lang.ps.Z            4-page M3 language description
pub/doc/m3lang.txt                (text version)
pub/doc/twelvechanges.txt      changes to M3 after SRC report, before books
pub/doc/m3brochure.ps.Z        1-page general brochure on M3
pub/doc/m3brochure.txt            (text version)
pub/doc/m3forcpp.ps.Z          1-page (legal-size) brochure on M3 for C++ users
pub/doc/m3forcpp.txt              (text version)

pub/lib/README                 what's in this directory
pub/lib/fl-1.0.tar.Z           FieldList library module

pub/usenet/README              what's in this directory
pub/usenet/FAQ                 answers to frequently-asked questions

	[The following are threads excerpted from the comp.lang.modula3
	discussions and edited.]

pub/usenet/divmod.txt          discussion of DIV and MOD
pub/usenet/equiv.txt           type equivalence in presence of initializers
pub/usenet/except.txt          discussion of exceptions and parameters
pub/usenet/generic.txt         discussion of generics
pub/usenet/initial.txt         providing and enforcing initialization
pub/usenet/inline.txt          discussion of inlining
pub/usenet/macros.txt          discussion of extensibility and macros
pub/usenet/opaque.txt          using and compiling opaque types
pub/usenet/productivity.txt    discussion of productivity of type-safe lang's

Here's the INDEX file:

TOPIC                SEE
-----------------    ----------------------------------------------------
books & articles     /pub/BIBLIO
brochures            /pub/doc/README
bulletin boards      /pub/usenet/README
C++                  /pub/doc/m3forcpp.txt
changes to files     /pub/CHANGES
comp.lang.modula3    /pub/usenet/README, /pub/usenet/FAQ
compilers            /pub/usenet/FAQ, /pub/usenet/opaque.txt
DEC SRC              /pub/FTP, /pub/usenet/FAQ
DIV                  /pub/usenet/divmod.txt
exceptions           /pub/usenet/exceptions.txt
FAQ (frequently
  asked questions)   /pub/usenet/FAQ
features of M3       /pub/doc/m3lang.txt
ftp instructions     /pub/FTP
generics             /pub/usenet/generic.txt, /pub/doc/twelvechanges.txt
initialization       /pub/usenet/initial.txt
inline expansion     /pub/usenet/inline.txt
macros               /pub/usenet/macros.txt
MOD                  /pub/usenet/divmod.txt
Modula-3 language    /pub/BIBLIO, /pub/doc/README, /pub/doc/twelvechanges.txt
Modula-3 News        /pub/m3news/README
newsgroups           /pub/usenet/README
newsletter           /pub/m3news/README
opaque types         /pub/usenet/opaque.txt
ordering stuff       /pub/ORDERS
Pine Creek Software  /pub/README
Prentice Hall        /pub/BIBLIO
productivity         /pub/usenet/productivity.txt
Real Time Associates /pub/BIBLIO
SRC Modula-3         /pub/FTP, /pub/usenet/FAQ
sweatshirts          /pub/ORDERS
Systems Programming
  with Modula-3      /pub/BIBLIO
t-shirts             /pub/ORDERS
type equivalence     /pub/usenet/equiv.txt
Total Information    /pub/BIBLIO
USENET               /pub/usenet/README

Let me know if there are problems.

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.


======================================================================== 7 ===
Date:    5 Jan 92 18:47:53 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: M3 books - int'l phone

In Modula-3 News #2 I included an 800 number for obtaining copies of the
Modula-3 books. This number is not useful to people outside the US; the
number they should use is listed below, with the company's address:

	Total Information
	844 Dewey Avenue
	Rochester, NY  14613
	USA
	Phone: +1 (716) 254-0621     in US: 1 (800) 876-4636
	FAX:   +1 (716) 254-0153

Sorry for the omission.


======================================================================== 8 ===
Date:    Wed, 8 Jan 92 09:46:56 EST
From:    wyant@saber.com
Subject: 2.0 Release ?

Any word on when the 2.0 release will occur ? Christmas
has come and gone, with no presents under the tree ;-)

Geoff Wyant


======================================================================== 9 ===
Date:    8 Jan 92 17:09:31 GMT
From:    dme@cl.cam.ac.uk (David Evers)
Subject: 1.6 s-l-o-w to compile many revelations?


I'm currently working on a stub generator for Modula-3, and have come
across what I think may be a performance problem with the SRC 1.6
compiler's handling of succcessive revelations.  The stub generator
is organised as a front-end and several back-ends around a central
abstract syntax tree.  The AST node types are not defined all in one
go; rather, each component of the stub generator defines its own
`view' of each AST node type.  The components are arranged into a
linear order, and each defines its view of a node by REVEALing the
total node type to be an opaque subtype of this component's view of that
node type, which is itself a (concrete) subtype of the previous view's
(concrete) view of the node type.  I pinched this organisation from
the late Olivetti M3 compiler (aka. m3tk these days).  It is described
in more detail in a paper by Mick Jordan in (I think) one of the
recent ACM Symposia on Practical Software Development Environments;
sorry I don't have the full reference handy.

To make this clearer, here's a picture (arrows mean IMPORT):


	AST.i3
	^  TYPE Node <: NodeP;
	|       NodeP = OBJECT END;
	|				  .............................
	|<--------------------------------.-View1.m3		      .
	|				  .			      .
	|<- View1.i3			  .			      .
	|   ^  REVEAL AST.Node <: Node;	  . REVEAL Node = AST.NodeP   .
	|   |  TYPE Node <: AST.NodeP;	  .  BRANDED OBJECT (*extras*).
	|   |				  .  END;                     .
	|   |				  .............................
	|   |<----------------------------.-View2.m3		      .
	|   |				  .     		      .
	|<- View2.i3			  . 			      .
	|   ^  REVEAL AST.Node <: Node;	  . REVEAL Node = View1.Node  .
	|   |  TYPE Node <: View1.Node;	  .  BRANDED OBJECT (*extras*).
	|   |				  .  END;                     .
	|   ...			          .............................
	|   ^
	|   |				  .............................
	|   |<----------------------------.-ViewN.m3	              .
	|   |				  .		              .
	|<- ViewN.i3			  .		              .
	|   ^  REVEAL AST.Node <: Node;	  . REVEAL Node = ViewN-1.Node.
	|   |  TYPE Node <: ViewN-1.Node; .  BRANDED OBJECT (*extras*).
	|   |				  .  END;                     .
	|   |				  .............................
	|<- ASTTotal.i3
	       REVEAL AST.Node = ViewN.Node BRANDED OBJECT END;

In my stub generator, N is about 9, and there are about 30 node types
(things like AST.Node in the picture).  Of course, not every view needs
to refine all the node types; those that a view does not refine are
passed through ViewN.i3 by saying something like

	REVEAL AST.UnchangedNode <: UnchangedNode;
	TYPE UnchangedNode = ViewN-1.UnchangedNode;

The interfaces View[1..N].i3 compile in a perfectly reasonable time.
However, the modules View[1..N].m3 take ages. On a Sun 4 with 32Mb of
real memory, going flat out at >90% user states with nothing else
running, they take from about 4 minutes for View1 to over 30 minutes
for View9.  What's worse, when I ill-advisedly added initialisation
procedures to the interfaces View[5..N].i3 and imported them into my
main module in order to guarantee a particular initialisation order,
the main module (about 30 lines in itself) took over 2 hours to
compile!  Needless to say, I scrapped that idea, and relied on the
module-initialisation sequencing rules of the language itself, which
in fact did the right thing.

At first I assumed that the fact that I was doing a lot of partial
revelations of the AST node types was hitting a less-than-perfect
compiler implementation of this language feature.  Now I'm not so
sure, given that (a) the interfaces don't take too long, whereas
the modules do, and that (b) the main module (which imported five
or so of the view interfaces, but made no revelations itself) took
so much longer.  I wonder if the compiler is just doing an exhaustive
depth-first traversal of the IMPORT graph rather than `pruning' when
it sees an interface it has already parsed (notice that each ViewN.m3
depends explicitly on ViewN-1.i3 and implicitly on ViewN.i3, whereas
each ViewN.i3 depends only on its predecessor and AST.i3).

Anybody know why this happens?  Is it better in 2.0?  I quite like
the view structure above (the alternative being property lists on
the AST nodes which each view can put its private data on), but
it's barely practical with the current M3 compiler.

							---- Dave

[David Evers                       Janet:  dme@uk.ac.cam.cl
 U. Cambridge Computer Lab (T76)   Inet:   dme%cl.cam.ac.uk@nsfnet-relay.ac.uk
 Corn Exchange Street              UUnet:  ...!uunet!mcvax!ukc!cam-cl!dme
 Cambridge CB2 3QG    U.K.         Phone:  +44 223 334639		     ]


======================================================================== 10 ===
Date:    Wed, 8 Jan 92 12:19:37 PST
From:    mjordan@src.dec.com (Mick Jordan)
Subject: Re: 1.6 s-l-o-w to compile many revelations?

Yes, this is a known problem in 1.6, for which there is no (easy) workaround.
It is why 'm3tk' is shipped with 1.6 using flattened ASTs containing a fixed
set of views.

The good news is that everything is fixed in 2.0, The bad news is that you dont
have it yet!

Since you are running on DECstations, it should be easy for you to get
2.0 up and running very soon. Perhaps you could persuade Bill and Eric to
give you a pre-beta-release?

Mick
 
PS

My 'fix' was to write a tool (based on the Modula-3 AST) which took a set of 
views and flattened them out into a single type declaration which, in your
example, was stored in a different version of ASTTotal.i3. I then used
conditional compilation in the clients, e.g.

#ifdef VIEWS
IMPORT View1, View2,...;
#lse
IMPORT ASTTotal
#endif

PPS

What AST are you specifying and what is the stub-generator? Just curious.



======================================================================== 11 ===
Date:    8 Jan 92 17:11:06 GMT
From:    dagenais@vlsi.polymtl.ca (Michel Dagenais)
Subject: Modula 3 newsletter

I just received the Modula 3 newsletter from Sam Harbinson (alias Pine
Creek Software). Looks very professional with pictures and everything.
After reading it i placed it in front of my office to give Modula 3 some
needed exposure. 

The Pine Creek archive announced last week also contains 
valuable information. I enjoyed the M3 for C++ programmers document. Thanks
for the good work!
--
---------------------------------------------------------------------

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

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


======================================================================== 12 ===
Date:    9 Jan 92 15:56:20 GMT
From:    dme@cl.cam.ac.uk (David Evers)
Subject: Re: 1.6 s-l-o-w to compile many revelations?


In article <1992Jan8.121937.17739@src.dec.com>, mjordan@src.dec.com
(Mick Jordan) writes:
|> 
|> What AST are you specifying and what is the stub-generator? Just curious.

The AST is for the ANSA IDL RPC interface definition language, which is
based on Xerox's Courier IDL.  The stub-generator converts an IDL interface
into a Modula-3 interface containing a Modula-3 object type definition for
the service.  It also generates server- and client-side stub modules.
These implement a second interface containing procedures to export
instances of the service object type to the outside world, and import
remote Ansa services as Modula-3 objects of the corresponding service type.

								---- Dave

[David Evers                       Janet:  dme@uk.ac.cam.cl
 U. Cambridge Computer Lab (T76)   Inet:   dme%cl.cam.ac.uk@nsfnet-relay.ac.uk
 Corn Exchange Street              UUnet:  ...!uunet!mcvax!ukc!cam-cl!dme
 Cambridge CB2 3QG    U.K.         Phone:  +44 223 334639		     ]


======================================================================== 13 ===
Date:    11 Jan 92 16:37:47 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: Modula-3 t-shirts & sweatshirts; get orders in

Repeating a previous post, Modula-3 t-shirts and sweatshirts are now
available. Many people responded to an earlier poll about wanting
t-shirts, but have not followed up with an order!

So, mail me a check ASAP. I'll be mailing out the shirts next Wednesday;
if I don't have your order by then, you'll have to wait until I return
from Uniforum and mail the next batch on 1/27.

Modula-3 T-shirt, 100% cotton, ash with maroon logo
  size L or XL      $6.00
  XXL                7.00

Modula-3 Sweatshirt (heavy), ash with maroon logo
  size L or XL      18.00
  XXL               21.00

Shipping & handling (per sweatshirt, or for up to 3 tees)
  US                 4.00 (priority mail)
  Canada             5.00
  Other              8.00 (surface)

Sam Harbison
Pine Creek Software
Suite 300
305 South Craig Street
Pittsburgh, PA 15213-3706
USA

harbison@bert.pinecreek.com
+1 (412) 681-9811


======================================================================== 14 ===
Date:    13 Jan 92 21:37:29 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: They're here...

Well, the mailman brought a copy of my new book, "Modula-3", today.
Hot off the presses, as they say, two days before the scheduled
in-stock date. So, I declare that the book officially exists. Ordering
info was posted earlier.


======================================================================== 15 ===
Date:    14 Jan 92 21:47:15 GMT
From:    nayeri@cs.umass.edu (Farshad Nayeri)
Subject: Compiling Modula-3 2.0 on SPARCstations


Can someone please let me know what modifications I have to make to the SPARC
distribution of Modula-3 to make it work on the SPARCstations? The compilation
process bombs because "includes/dota.base" needs a file "float.h" that does
not exist on (our) SPARCstations.

Thank you in Advance,

Farshad Nayeri
GTE Laboratories

--
--
Farshad Nayeri                Object Oriented Systems Group
nayeri@cs.umass.edu           Dept. of Computer and Information Science
(413)545-0256                 University of Massachusetts at Amherst


======================================================================== 16 ===
Date:    14 Jan 92 17:07:43 GMT
From:    mjl@cs.rit.edu (Michael J Lutz)
Subject: Review of Nelson book in IEEE Software


The January 1992 issue of IEEE Software contains a glowing
review of "Systems Programming with Modula-3".  I should know:
I wrote it!  A helpful bit of publicity for Modula-3, I hope.

If you read the review, let me know what you think.  Positive
responses can be posted here; negative ones can be sent to
me privately :-)


Michael Lutz
Department of Computer Science
Rochester Institute of Technology
Rochester, NY 14623-0887  USA
+1 (716) 475-2472
mjl@cs.rit.edu


======================================================================== 17 ===
Date:    Wed, 15 Jan 92 09:37:05 EST
From:    wyant@saber.com
Subject: Official status of 2.0 area ?

What is the "official" status of the m3-2.0
directory on gatekeeper. I've put off getting
and building it until some public announcement
was made.

cheers,

geoff



======================================================================== 18 ===
Date:    Wed, 15 Jan 92 08:37:47 PST
From:    <kalsow@src.dec.com>
Subject: Official status of 2.0 area

There is a preliminary copy of version 2.0 on gatekeeper.  It's there 
so that a few brave and friendly people can try installing it on 
their systems.

We've tested the DECstation and VAX versions.  Others are testing 
the SPARC and Multimax versions.  As far as we know, nobody has tried 
the AIX/386, Apollo, ARM, HP300, IBM R2, IBM RT or SUN 3 versions.  
If you do try installing the system, expect problems.  It's impossible 
for us to get everything right without testing on real systems.

We'll send another message when we believe that the release
is stable enough for the masses.

  - Bill Kalsow


======================================================================== 19 ===
Date:    Thu, 16 Jan 1992 00:22:32 GMT
From:    bill@cs.columbia.edu (Bill Schilit)
Subject: testers needed...

I just wrote some functions to interface GNU emacs to the release 2.0
m3pp program (thanks for the improvements Dave!).  I'm looking for
people interested in shaking it out for bugs before I post it here.
It helps if you know elisp.  A description is below.  I've managed to
use m3pp to do line at a time indentation (replacing leading spaces)
or pretty printing (replacing the current line).


;; Modula-3 pretty printer (m3pp) interface for GNU Emacs.

;; Interactive functions (put these on keys):
;;
;;  m3pp-declaration
;;   Replace region starting at previous top-level declaration, BEGIN block,
;;   or beginning of buffer with 'm3pp' version.
;;
;;  m3pp-indent-line
;;   Indent current line using 'm3pp'.
;;
;; User settable variables:
;;
;;  m3pp-program-name
;;   Program invoked by 'm3pp' commands.
;;
;;  m3pp-program-switches
;;   Program switches for 'm3pp'.
;;
;;  m3pp-indent-prettily
;;   When indenting, replace current line with 'm3pp' version.
;;

- Bill
-- 
Bill Schilit
Columbia University Computer Science Department
bill@cs.columbia.edu


======================================================================== 20 ===
Date:    Wed, 15 Jan 1992 19:31:48 GMT
From:    nr@cs.Princeton.EDU (Norman Ramsey)
Subject: Proposed addition to the UnsafeRd interface


To speed up lexical analysis, I am using the UnsafeRd interface, so
that I lock the reader at every token instead of at every character.
I added a new procedure, FastUnGetChar, to the UnsafeRd interface,
because otherwise I would have had to break the lock before calling
Rd.UnGetChar.  I suggest that many users of the UnsafeRd interface may
find themselves in similar situations, and I propose that
UnsafeRd.FastUnGetChar be added to the distribution, even though it's
not considered a ``performance-critical'' operation.
-- 
Norman Ramsey
nr@princeton.edu


======================================================================== 21 ===
Date:    Wed, 15 Jan 92 18:39:44 PST
From:    muller@src.dec.com (Eric Muller)
Subject: SRC Modula-3 2.01 (beta version) available

SRC Modula-3 2.01 (a beta version) is available from
gatekeeper.dec.com in pub/DEC/Modula-3/m3-2.0.

This version has been successfully installed on a DECstation and on a
VAX.  We have integrated bug fixes for the SPARC installation and we
believe it should work ok.  Other machines have not been tested (as
far as we know).  You need to start with
boot.<architecture>-2.01.tar.Z and libm3-2.01.tar.Z (see the README
file in pub/DEC/Modula-3/m3-2.0).

Look at the top level README in the boot.<architecture> archive to
know what the expected problems are.

Expect some problems with this version.  If you are willing to spend
some time, please try to install it and tell us what the problems are.
If you don't have time, you may prefer waiting for a future, more
stable release.

Thanks for your help.

-- 
Eric.



======================================================================== 22 ===
Date:    16 Jan 92 17:26:29 GMT
From:    loverde@ux1.cso.uiuc.edu (AstralWolf)
Subject: PC Compiler needed...


  A course at my school recently changed to Modula-3, and I am desparately
looking for a PC version of Modula3  Does anyone know of either
a commercial version (if so could you mail me the name)  or a 
pd or shareware version, and preferably an FTP site where I can get it?
It would be greatly appreciated....

-- 

-------------------------------------------------------------------------------
! "Those who THINK they know it all   !              AstralWolf               !
!  are very annoying to those of us   !          aka Jim LoVerde              !


======================================================================== 23 ===
Date:    Thu, 16 Jan 92 11:37:10 PST
From:    muller@src.dec.com (Eric Muller)
Subject: 2.01 fix for libm3 for SPARC

In the archive libm3, the file Csupport/src/SPARC/m3makefile has a wrong line:

PGM_SOURCES ++= -X1_-I##SOURCE_DIR##Csupport/src/SPARC_

This line should be:

PGM_SOURCES ++= -X1_-I##SOURCE_DIR##_

-- 
Eric.




======================================================================== 24 ===
Date:    17 Jan 92 01:52:54 GMT
From:    do12+@andrew.cmu.edu (Dick Orgass)
Subject: Simple fixes for 2.01 on IBMR2

My compliments to Eric for a job well done!  Building the compiler,
driver and core library was the easiest so far.  

I ran into a few minor problems when building both boot.IBMR2 and
libm3.a.  They're trivial except for the first one:

Declaration of _M3__handlers and _M3__stackLimit in M3Runtime.h

When compiling ThreadF_i.c, RTException_m.c and Thread_m.c, the C
compiler for the RISC 6000 complains that one or both of the above
symbols are redeclared when compared to the declarations in M3Runtime.h.
 This is also true when the Modula-3 core library is compiled from the
Modula-3 source.

As a temporary work around, I worked as follows.  First I compiled
boot.IBMR2 allowing the compiles of these files to fail.  Next, I
commented out these two declarations while compiling the offending
files.  Then I restored the declarations.

I repeated the same steps when building the core library.

This is a work around to get going but I would hope that there is a
better solution for the "production" version of the compiler/library. 
Unfortuantely, I don't have any good ideas at the moment.

Declarations in M3Machine.h

The C compiler for RISC 6000 does not accept declarations of static
volatile, extern volatile and volatile for functions.  Accordingly, the
declarations of _PRIVATE, _IMPORT and _EXPORT in M3Machine.h must be
changed as shown in this code fragment.  The commented text is replaced
with the uncommented text.

    /*define _PRIVATE static volatile*/
    #define _PRIVATE static
    /*define _IMPORT  extern volatile*/
    #define _IMPORT  extern
    /*define _EXPORT         volatile*/
    #define _EXPORT

Defining -z3 for config.c

For some reason, the config.c generated by the build process leaves the
text "-z3" in config.c causing m3 to complain about an invalid option
whenever it is invoked.  Here is the change that I made to this source
file; your library directory will be different.

    "-z3@/u/decsrc/lib/m3/report_coverage.o@"

I suspect that this is a problem with the AIX 3.1 version of sed.

Use of awk when building

The product version of awk emits error messages when modifying some C
source file.  I didn't take the time to do a major amount of work to
find out the name of the source file.  Instead, I simply changed to GNU
awk, gawk and all went well.

I'll report further when I've run the tests and built the library.

Dick


======================================================================== 25 ===
Date:    17 Jan 92 14:03:10 GMT
From:    stabl@fmi.uni-passau.de (Robert Stabl)
Subject: Modula3 for NeXT

Is there any version of Modula3 for NeXT? If not are there any plans of porting
  
it to this computer?

Regards
 Robert Stabl.

--
>>>>>>>> Robert Stabl <<<<<<<>>>>>>>>> stabl@fmi.uni-passau.de <<<<<<<<
> Dept. of Computer Science <>>>>>>>>>>>> (NeXTmail welcome) <<<<<<<<<<
>>>> University of Passau <<<>>>>>>>>> Phone: +(49)851/509-711 <<<<<<<<
>>> D-8390 Passau, Germany <<>>>>>>>>>> Fax: +(49)851/509-497 <<<<<<<<<


======================================================================== 26 ===
Date:    17 Jan 92 17:14:31 GMT
From:    do12+@andrew.cmu.edu (Dick Orgass)
Subject: Missing object file for IBMR2

For version 2.01, the Modula-3 core library, libm3.a, must include a
special version of setjmp.o which was distributed with version 1.6
because the product version prohibits long jumps other than back into
the current stack.

As a quick fix, copy .ROOT/system/corelib/coreos/setjmp.o from the 1.6
distribution into libm3/IBMR2 and then execute the command

    ar ru libm3.a setjmp.o

in that directory.  This should be done after the library is built and
before it is installed.

Eric or Bill -- Would you be willing to add this file to your
distribution and modify m3makefile so that it's built correctly?  I'll
be glad to send you another copy of the file if you don't have the 1.6
distribution available.  Thanks!

Dick


======================================================================== 27 ===
Date:    Fri, 17 Jan 92 17:02:00 -0500
From:    Norman Ramsey <nr@Princeton.EDU>
Subject: RTMisc.RaisesFault

Would be a hell of a lot more helpful if it gave the name of the
procedure that doesn't have an exception on its raises list.

Norman


======================================================================== 28 ===
Date:    18 Jan 92 03:40:31 GMT
From:    PNCSPPC@CCVAX1.CC.NCSU.EDU
Subject: Test (of ucbvax mail server)

Sorry!  Just a test message.


======================================================================== 29 ===
Date:    20 Jan 92 19:36:06 GMT
From:    paul@uxc.cso.uiuc.edu (Paul Pomes - UofIllinois CSO)
Subject: porting to a new host

I'm installing Modula-3 on a Sequent Symmetry running Dynix 3.1.  I've
already got it running on a VAX-3500 with 4.3 BSD-reno.  As I understand
it, I need to create a Target.i3 file for the Sequent (done), and then
generate a cross-compiler, followed by using that cross-compiler to create 
C code of the driver and compiler to compile on the Sequent.

Can anyone provide explicit directions for the last two steps?  I'm not
all that familiar with Modula-3 as I'm installing it for use by a CS
class here.  All help is appreciated.

/pbp
-- 
Paul Pomes, Univ of Illinois  |  Necessity is the argument of tyrants, it is
Email to Paul-Pomes@uiuc.edu  |  the creed of slaves.  --William Pitt (1783)


======================================================================== 30 ===
Date:    21 Jan 92 16:19:08 GMT
From:    charon@opal.cs.tu-berlin.de (Sebastian Mix)
Subject: Re: Modula3 for NeXT

stabl@fmi.uni-passau.de (Robert Stabl) writes:

>Is there any version of Modula3 for NeXT? If not are there any plans of portin
g  
>it to this computer?
>
>Regards
> Robert Stabl.
I'd be very interested, too (although M2 or Oberon would do it, too).

--
-------------------------------------------------------------------------------
-
Sebastian Mix, Eichhornstr.5-6 Apt.222, D-1000 Berlin 30, T: (030) 262 1811 /(a
\
charon@cs.tu-berlin.de  |  charabib@w250zrz.zrz.tu-berlin.de (no NeXTmail)  \p)
/
-------------------------------------------------------------------------------
-


======================================================================== 31 ===
Date:    22 Jan 92 15:21:54 GMT
From:    dagenais@vlsi.polymtl.ca (Michel Dagenais)
Subject: SRC 2.0 library

Looking at the content of the libraries that come with Modula 3 SRC 2.0, i
have a few questions. 

- the library seems to include all the goodies found in other libraries
  (like libg++ or nihcl in the C++ world) and then some (Pickles, Threads,
  Geometry...). I have not seen anything on regular expressions (only stuff
  to recognize standard tokens like ints, floats...), often found in other
  libraries, did i miss anything?

- is the only documentation the comments in the interface files? Although
  it is sufficient for simple modules, it is hard to grasp for larger
  systems like Trestle. Are there other sources of documentation?
  I noticed TeX commands within the Trestle comments, is that part of
  some kind of simple "litterate programming" package?

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

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

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


======================================================================== 32 ===
Date:    Wed, 22 Jan 92 17:14:26 PST
From:    muller@src.dec.com (Eric Muller)
Subject: m3-request dead ? no, simply sick

I was sick during the past week.  If you have sent a message to
m3-request, chances are that nobody answered.  Don't despair, I am
back again behind my keyboard.

-- 
Eric.



======================================================================== 33 ===
Date:    Wed, 22 Jan 92 11:28:07 PST
From:    <gnelson@src.dec.com>
Subject: Re: SRC 2.0 library


Michel Dagenais is correct that the TeX commands in the Trestle interfaces
shipped with SRC Modula-3 version 2.0  are part of a simple literate 
programming package.  The typeset output of the package is now being 
printed as the Trestle Reference Manual; I will post a message when 
it comes back from the printer. 

I expect we will make the literate programming package available to 
others, after we get a bit more experience with it at SRC.

Greg Nelson


======================================================================== 34 ===
Date:    Wed, 22 Jan 92 14:41:03 EST
From:    wyant@saber.com
Subject: SRC 2.0 library

For Trestle, at least, there is a DEC SRC Technical Report in 
progress. There is an early (but useful&mostly complete) 
version that is in the 1.6 Trestle sources under the m3
directory on gatekeeper (trestle.tar.Z). You might FTP that
and then throw away everything but the Doc directory.

I don't know if there are plans to write any extensive documentation
on the provided libraries. I would doubt it as the SRC people are
probably busy enough getting the full 2.0 release into shape (from
the 'checklist' section of doc provided with 2.0, it seems that
there are a number of libraries yet to come).

cheers,

geoff


======================================================================== 35 ===
Date:    Wed, 22 Jan 1992 23:59:03 GMT
From:    nr@cs.Princeton.EDU ()
Subject: Pragmas I would like to see


TYPE
  <*CLASS*> Object = OBJECT ... END;
  Instance1 = Object OBJECT ... END;
  Instance2 = Object OBJECT ... END;
   ...
  InstanceN = Object OBJECT ... END;

The <*CLASS*> pragma should have two effects:

  -- The compiler bitches if anyone writes NEW(Object, ...)
  -- The compiler does not bitch if Object is the only alternative
     missing from a TYPECASE, e.g.
         VAR o : Object;
         BEGIN
           TYPECASE o OF
           | Instance1, Instance2, ... InstanceN => ...
           END;
         END;
     should draw no warnings.

-- 
Norman Ramsey
nr@princeton.edu


======================================================================== 36 ===
Date:    Wed, 22 Jan 1992 20:26:16 GMT
From:    andru@electron.LCS.MIT.EDU (Andrew Myers)
Subject: inline methods?


How do I get the effect of C++ inline methods in Modula-3? I want to
be able to package up a set of operations in an interface, but have
any usage of some operations be inlined. This is clearly a violation
of the interface/implementation separation, yet such a useful one...

Andrew


======================================================================== 37 ===
Date:    Wed, 22 Jan 92 13:15:00 PST
From:    mjordan@src.dec.com (Mick Jordan)
Subject: Re: inline methods?

There is no compiler support for the INLINE pragma at present, but see article 
624
in this newsgroup for an alternative approach.

Mick Jordan


======================================================================== 38 ===
Date:    Wed, 22 Jan 92 19:31:30 PST
From:    msm@src.dec.com (Mark S. Manasse)
Subject: Re: Pragmas I would like to see

You also want to prohibit other occurrences of Object OBJECT ... END,
or else you can't be sure that you have exhausted the list of subtypes.

Mark


======================================================================== 39 ===
Date:    23 Jan 92 16:55:30 GMT
From:    prj@gamba.lcs.mit.edu (Paul R. Johnson)
Subject: Runtime errors

Another SRC Modula-3, 2.0, question.  How are "checked runtime errors"
reported?

---Paul


======================================================================== 40 ===
Date:    23 Jan 92 15:46:42 GMT
From:    prj@gamba.lcs.mit.edu (Paul R. Johnson)
Subject: Exception semantics

In section 5.4 ("Language restrictions") of the SRC Modula-3, Version 2.0,
documentation manual, it is said that the setjmp/longjmp mechanism used
to implement exception handling can lead to assignments being undone.
This I understand.  What I don't understand is how Modula-3 programmers
cope with this.  Is it necessary to always keep this in mind when using
TRY ... EXCEPT ... END; ?  Are there special tricks to help cope?

---Paul R. Johnson


======================================================================== 41 ===
Date:    23 Jan 92 16:00:12 GMT
From:    dagenais@vlsi.polymtl.ca (Michel Dagenais)
Subject: Object browser for inspection/debugging

I am looking at the possibility of implementing a simple object browser to
help in debugging. Here is one way to go which would not be too complex but
i am not really satisfied with it. Suggestions?

- start a separate thread that opens a window, maintains a list of
  displayed objects, updates the displayed objects every second or so
  and awaits user input.

- through the debugger, references of type ANY can be added to the list
  of displayed objects.

- for each object to display, ask for the type code and call the
  associated PrintProc. Get the printed version as TEXT, parse it to
  detect the position/rank of nested references to other objects, and finally
  display the object.

- if the user clicks on the position of a nested reference to another
  object, the rank of this reference within the object is noted and 
  the VisitProc is called to access all the nested objects and add
  to the display list the desired object (determined by its rank).

Obviously some contorsions are due to the limited number of procedures
available to access type information. If one could know the list
of data members in the object and their type (and name), it would be much
easier to know which nested object the user wants to display. Maybe this
information is there waiting for me and i have missed it ?
--
---------------------------------------------------------------------

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

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


======================================================================== 42 ===
Date:    22 Jan 92 15:47:03 GMT
From:    lilleyc@cs.man.ac.uk (Chris Lilley)
Subject: Re: Modula-3

In article <DAGENAIS.92Jan21120538@pollux.vlsi.polymtl.ca> dagenais@vlsi.polymt
l.ca (Michel Dagenais) writes:

 >I would presume that switching from Modula 2 to Modula 3 would be a more 
 >natural path but i dont see many people discussing this issue in this
 >newsgroup. Are many Modula 2 users considering the switch? Is the lack of a
 >PC Modula 3 compiler the major obstacle?

On the nail. *THE* major obstacle, I would say.

I note that some universities are now teaching M3.  That should help.

Oh - btw I have redirected followups to comp.lang.modula3

	Chris


======================================================================== 43 ===
Date:    Thu, 23 Jan 92 14:02:15 PST
From:    mjordan@src.dec.com (Mick Jordan)
Subject: Re: Object browser for inspection/debugging

In article <DAGENAIS.92Jan23110012@pollux.vlsi.polymtl.ca>, dagenais@vlsi.polym
tl.ca (Michel Dagenais) writes:
> I am looking at the possibility of implementing a simple object browser to
> help in debugging. Here is one way to go which would not be too complex but
> i am not really satisfied with it. Suggestions?

> - for each object to display, ask for the type code and call the
>   associated PrintProc. Get the printed version as TEXT, parse it to
>   detect the position/rank of nested references to other objects, and finally
>   display the object.
> 

One problem is that in 2.0 the printprocs have gone away - they were a consider
able
component in the large image sizes. In the Olivetti implementation we handled t
his
a different way and it might be the basis of something you could work on. Since
 we
had the abstract syntax tree around at pre-link time (at least for declarations
 and
types), we were able to generate an encoding of a type, including the
record/object/enumeration field names, as a TEXT, and store it in a global tabl
e,
indexed by typecode. We then had a module which interpreted this information to
display the values from the debugger. I have occasionally considered running th
e
AST based pre-linker to generate this information and link it in to code genera
ted
by the SRC compiler. There needs to be a map between the typecodes generated by
 the two
systems, since they are not the same. However, I have some plans to do this any
way
as part of another project.

If you would like to pursue this, I would be happy to help out (especially with
 the
lack of documentation on m3tk). On the latter issue I can say that there is a 2
.0 version
of m3tk that will ship soon and there will be documentation coming in the first
 half
of the year.

Mick Jordan
 


======================================================================== 44 ===
Date:    Thu, 23 Jan 92 15:16:38 EST
From:    wyant@centerline.com
Subject: Object browser for inspection/debugging

You might be able to build something interesting
with 'm3tk', the Modula-3 AST toolkit written by
Mick Jordan (this formerly the guts of the Olivetti
M3 compiler). The only drawback is the lack of
documentation. 

The only information directly available at runtime
is type information through typecodes. You could look
at the Pkl code to get a feel for traversing type 
structures. This won't give you names of fields though.

A  very crude hack would be to see if an object had a
method defined that yield up field names. If the instance
had such a method, call it to get field names. Otherwise,
label the fields numerically...

--Geoff Wyant





======================================================================== 45 ===
Date:    Fri, 24 Jan 1992 01:03:28 GMT
From:    nr@cs.Princeton.EDU ()
Subject: Reducing garbage collection overhead in SRC M3 1.6

My interpreter was slow and was spending much too much of its time
(over 40%) garbage collecting.  prof(1) reported:

  %time     seconds  cum %   cum sec  procedure (file)

   12.7     50.1200   12.7     50.12 _RTMath__IDiv (007079000_m.c)
   10.1     40.0900   22.8     90.21 _RTHeap__Move (007058000_m.c)
    7.1     27.9600   29.9    118.17 _RTHeap__ReferentSize (007058000_m.c)
    6.0     23.6400   35.9    141.81 _RTHeap__ReferentToPage (007058000_m.c)
    4.8     18.9300   40.7    160.74 _RTHeap__Collect (007058000_m.c)

(The RTHeap module contains several instances where integers are
divided by 2048.  These divisions require calls to RTMath.IDiv because
the integers are not known to be non-negative.)  I first did some code
tuning of RTHeap, trying to replace divisions by shifts when possible.
Tuning increased execution time by only a few percent.

I turned to a paper by Appel that discusses copying garbage
collection.  Appel defines *gamma* to be the ratio of heap size to
live data.  His garbage collector has a parameter gamma_0, which is
the desired value of gamma.  I modified RTHeap.LongGcalloc and
RTHeap.GrowHeap to ensure that gamma >= gamma_0 whenever the heap has
to grow.  gamma_0 = 3.0 by default (the default value used by Appel),
but I added a procedure RTHeapRep.SetGamma to change its value.

Here are the execution times required by my program using the original
and modified collectors.  All times are elapsed time on a lightly
loaded DS3100 with 16M of physical memory:

    original         152.44 +/- 4.27 sec  (n = 10, stddev = 13.49)	1.92
    gamma_0 = 3.0     93.59 +/- 1.22 sec  (n = 10, stddev =  3.86)	1.18
    gamma_0 = 4.0     88.08 +/- 3.01 sec  (n =  5, stddev =  6.72)	1.11
    gamma_0 = 5.0     79.24 +/- 0.55 sec  (n =  5, stddev =  1.24)	1.00

To estimate the amount of ``wasted'' memory, I ran with
gamma_0 = 5.0 and (at the end) queried the GC status, which reported

    allocated = 5000, active = 1430, gamma = 3.5, gamma0 = 5.0

Indicating that 2140 pages or about 4.2 MB were ``wasted'' over the
bare minimum gamma = 2.0.  But, of course, the whole point of copying
collection is to trade large heap size for faster execution, so I'm
happy. 

With gamma_0 = 5.0, garbage collection is relatively unimportant;
prof(1) indictates

  8.3     16.3900    8.3     16.39 _InterpScan__Token (InterpScan.nw)
  7.7     15.2600   16.0     31.65 _UnsafeRd__FastGetChar (0095e000_m.c)
  6.3     12.4800   22.3     44.13 _RTType__IsSubtype (00704a000_m.c)
  5.6     11.0200   27.9     55.15 _UnsafeWr__FastPutChar (00727d000_m.c)
  5.1     10.1600   33.1     65.31 _RTMath__IDiv (007079000_m.c)
  4.7      9.3000   37.8     74.61 _InterpDict__DoAtom (InterpDict.nw)

InterpScan.Token is my lexical analyzer, and InterpDict.DoAtom looks
up a value in a hash table.

I append to this posting a reference to Appel's article and the diffs
for RTHeap.m3 and RTHeapRep.m3 (which include code tuning I shouldn't
have wasted my time on).


Norman Ramsey
nr@princeton.edu

@article{appel:simple,
  author = "Andrew W. Appel",
  title = "Simple Generational Garbage Collection and Fast Allocation",
  journal = "Software---Practice/Experience",
  year=1989, month="February", volume="19", number="2", pages="171--183"}

*** RTHeapRep.i3.orig   Wed Mar 27 11:45:07 1991
--- RTHeapRep.i3        Thu Jan 23 16:07:47 1992
***************
*** 161,162 ****
--- 161,165 ----

+ PROCEDURE SetGamma (gamma0 : REAL);
+   (* the desired minimum ratio of heap size to live data; default 3.0 *)
+   (* Appel recommend 3 to 7 for SML/NJ *)

*** RTHeap.m3.orig      Wed Mar 27 11:45:10 1991
--- RTHeap.m3   Thu Jan 23 19:03:17 1992
***************
*** 8,10 ****

! IMPORT RTType, RTTypeRep, RTMisc, ThreadF, RTLink, ThreadF, Cstdlib, CoreOS;
  FROM RTType IMPORT Typecode;
--- 8,10 ----

! IMPORT RTType, RTTypeRep, RTMisc, ThreadF, RTLink, ThreadF, Cstdlib, CoreOS, 
W
ord;
  FROM RTType IMPORT Typecode;
***************
*** 88,90 ****
    BEGIN
!     RETURN (s + 1) MOD MaxSpace;
    END NextSpace;
--- 88,93 ----
    BEGIN
!     IF s + 1 = MaxSpace THEN
!       RETURN 0;
!     ELSE
!       RETURN s + 1; END;
    END NextSpace;
***************
*** 209,211 ****
  PROCEDURE ReferentSize (h: RefHeader): CARDINAL =
!   VAR def: RTTypeRep.Definition; res: INTEGER;
    BEGIN
--- 212,214 ----
  PROCEDURE ReferentSize (h: RefHeader): CARDINAL =
!   VAR def: RTTypeRep.Definition;
    BEGIN
***************
*** 215,218 ****
      IF h^ = FillHeaderN THEN
!       res := LOOPHOLE (h + ADRSIZE (Header), UNTRACED REF INTEGER)^;
!       RETURN res - BYTESIZE (Header); END;

--- 218,221 ----
      IF h^ = FillHeaderN THEN
!       RETURN Word.Minus(LOOPHOLE(h + ADRSIZE (Header), UNTRACED REF INTEGER)^
,
BYTESIZE(Header)); (* compiler rejects `-' ?! *)
!       END;

***************
*** 234,244 ****
                               + ADRSIZE (UNTRACED REF INTEGER), (* elt pointer
*
)
!                            UNTRACED REF INTEGER); BEGIN
!
!         res := 1;
          FOR i := 0 TO def.nDimensions - 1 DO
!           res := res * sizes^;
            INC (sizes, ADRSIZE (INTEGER)); END;
!         res := res * def.elementSize; END;
!
!       res := Upper (res + def.dataSize, BYTESIZE (Header));
      ELSE
--- 237,251 ----
                               + ADRSIZE (UNTRACED REF INTEGER), (* elt pointer
*
)
!                            UNTRACED REF INTEGER);
!         tempres : INTEGER := 1; (* suppress check for res >= 0 *)
!                                 BEGIN
          FOR i := 0 TO def.nDimensions - 1 DO
!           tempres := tempres * sizes^;
            INC (sizes, ADRSIZE (INTEGER)); END;
!         tempres := tempres * def.elementSize;
!         IF tempres < 0 THEN
!           RETURN -1; (* cause fault *)
!         ELSIF BYTESIZE(Header) = 4 THEN (*true in current implementation, but
play safe*)
!           RETURN Word.And(tempres + def.dataSize + 3, Word.Not(3));
!         ELSE
!           RETURN Upper (tempres + def.dataSize, BYTESIZE (Header)); END; END;
      ELSE
***************
*** 245,249 ****
        (* the typecell datasize tells the truth *)
!       res := def.dataSize; END;

-     RETURN res;
    END ReferentSize;
--- 252,255 ----
        (* the typecell datasize tells the truth *)
!       RETURN def.dataSize; END;

    END ReferentSize;
***************
*** 270,275 ****
  PROCEDURE ReferentToPage (r: RefReferent): Page =
!   VAR p: Page;
    BEGIN
-     p := LOOPHOLE (r, INTEGER) DIV BytesPerPage;
-
      IF p < firstAllocatedPage
--- 276,279 ----
  PROCEDURE ReferentToPage (r: RefReferent): Page =
!   VAR p: Page := LOOPHOLE (r, INTEGER) DIV BytesPerPage;
    BEGIN
      IF p < firstAllocatedPage
***************
*** 283,288 ****
  PROCEDURE HeaderToPage (r: RefHeader): Page =
!   VAR p: Page;
    BEGIN
-     p := LOOPHOLE (r, INTEGER) DIV BytesPerPage;
-
      IF p < firstAllocatedPage
--- 287,290 ----
  PROCEDURE HeaderToPage (r: RefHeader): Page =
!   VAR p: Page := LOOPHOLE (r, INTEGER) DIV BytesPerPage;
    BEGIN
      IF p < firstAllocatedPage
***************
*** 485,488 ****
    VAR
!                  actualInc := MAX (ROUND (FLOAT (allocatedPages) * 0.2),
!                                    MAX (HeapMinIncrement, minInc));
                   newChunk  := Cstdlib.malloc ((actualInc + 1) * BytesPerPage)
;
--- 487,490 ----
    VAR
!                  actualInc := MAX (CEILING(gamma0*FLOAT(activePages))-allocat
e
dPages,
!                               MAX (HeapMinIncrement, minInc));
                   newChunk  := Cstdlib.malloc ((actualInc + 1) * BytesPerPage)
;
***************
*** 744,747 ****
                 we want to have some room for the next allocation *)
!             IF previousActivePages - activePages < HeapMinIncrement DIV 2 THE
N
!               EVAL GrowHeap (0); END;

--- 746,750 ----
                 we want to have some room for the next allocation *)
!             IF ROUND(FLOAT(activePages)*gamma0) > allocatedPages
!             OR previousActivePages - activePages < HeapMinIncrement DIV 2 THE
N
!               EVAL GrowHeap(0); END;

***************
*** 1352,1353 ****
--- 1355,1365 ----
        PutInt (stderr, activePages);
+       PutText (stderr, ", gamma = ");
+       PutInt (stderr, allocatedPages DIV activePages);
+       PutText (stderr, ".");
+       PutInt (stderr, ((20 * allocatedPages + activePages) DIV (2*activePages
)
) -
+                       10 * (allocatedPages DIV activePages));
+       PutText (stderr, ", gamma0 = ");
+       PutInt (stderr, TRUNC(gamma0));
+       PutText (stderr, ".");
+       PutInt (stderr, TRUNC(10.0*gamma0+0.5)-10*TRUNC(gamma0));
        PutText (stderr, "\n");
***************
*** 1411,1412 ****
--- 1423,1429 ----
    END VisitAllRefs;
+
+ VAR
+   gamma0 := 3.0; (* desired ratio of heap size to live data *)
+
+ PROCEDURE SetGamma(gamma:REAL) = BEGIN gamma0 := MAX(gamma,2.1); END SetGamma
;

-- 
Norman Ramsey
nr@princeton.edu


======================================================================== 46 ===
Date:    24 Jan 92 15:39:46 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: Object browser for inspection/debugging

Our GNU M3 system is expected to support of TYPEOF operator that will return a
data structure describing the type of the argument to TYPEOF. This would let
you write browsers fairly easily. However, this feature is not a required part
of M3, so would not necessarily work in other implementations.
--

		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


======================================================================== 47 ===
Date:    24 Jan 92 19:04:59 GMT
From:    nr@cs.Princeton.EDU
Subject: Three language changes I would like to see

I don't know whether the language committee will consider any more
changes, but here are three changes I would like to see.

1) If p is a reference to an array, then permit expressions
        FIRST(p)  (* == FIRST(p^) *)		
        LAST(p)   (* == LAST(p^) *)		

2) Promote ASSERT from a pragma to a statement, so that
        ASSERT e
   causes a runtime error when e is FALSE.  Don't permit
   implementations to ignore ASSERT.

3) Make Word.T a type distinct from INTEGER and require explicit
   conversions from one to the other, perhaps using ORD and VAL.  (It
   may be best to add a new builtin type, WORD.)  Permit the usual
   arithmetic notation +, -, * DIV, MOD, and so on, with the same
   meanings as the procedures in the Word interface.

   I have two justifications for this proposal.  First, I would like
   the type system to protect me from inadvertently using signed
   arithmetic on a variable that is meant to be unsigned.  Second, the
   infix notation would improve the readability of my programs that do
   unsigned arithmetic.
-- 
Norman Ramsey
nr@princeton.edu


======================================================================== 48 ===
Date:    25 Jan 92 02:28:53 GMT
From:    sharon@lcs.mit.edu (Sharon Perl)
Subject: Problems with Fmt interface

It would be nice if the REALs printed by the Fmt interface were valid Modula-3
literals. Currently, using the AltSci format or the Mix format, the
real number "0.0001" might print as "1.D-4", for example, which is invalid
Modula-3 because a digit must follow the decimal point.  Fmt should provide a
mode that produces valid Modula-3 literals,  giving as much precision as
possible when printing REALs (or LONGREALs) without producing lots
of trailing zeros for numbers that don't require many digits.

Now, this is not as inconvenient as it could be at the moment, because
apparently, the compiler (and the Convert module) accepts input of
the form "1.D-4" as a valid LONGREAL.  But this is a bug because the M3
reference manual clearly states that there must be a non-empty sequence of
digits following the decimal point (p. 51 of Greg Nelson's book).

Also, I noticed a bug in Fmt.m3. Fmt.LongReal and Fmt.Real use a buffer of 101
CHARS ([0..100]), but never check whether their "precision" argument will cause
the buffer to overflow. Calling Fmt.LongReal with Style.Flo and a precision of
100 causes a runtime error.

Sharon Perl
sharon@lcs.mit.edu


======================================================================== 49 ===
Date:    25 Jan 92 08:33:46 GMT
From:    andru@electron.lcs.mit.edu (Andrew Myers)
Subject: Modula-3 difficulties

In trying to understand how the current Modula-3 implementation
handles objects, I generated the following interface and module.
The compiler reports that the RHS of TYPE a = .... assignment should
be a branded type. I don't understand why this is the case.

"t1.m3", line 5: right-hand side must be a branded type expression (a)

What I was trying to investigate was how Modula-3 handles subtyping
off an opaque type which is known to be an object type. From my
reading of the language definition, this should be legal, though
I can easily imagine reasons why it might have trouble doing what
I asked for...

------------ interface -------------
INTERFACE t1;
TYPE a <: ROOT;

TYPE b = a OBJECT
	f,g: INTEGER;
METHODS
	print();
END;
END t1.
-------------- implementation ----------------
MODULE t1;
FROM Wr IMPORT PutText;
FROM Stdio IMPORT stdout;

REVEAL a = OBJECT e: INTEGER; END; (*** This is the line the error is on ***)

TYPE b2 = b OBJECT f,g: INTEGER; OVERRIDES print := print_; END;

PROCEDURE print_(bobj: b2) =
BEGIN
    PutText(stdout, "printing a b\n");
END print_;

BEGIN END t1.


======================================================================== 50 ===
Date:    25 Jan 92 00:25:26 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: Object browser for inspection/debugging

In article <MOSS.92Jan24103946@ibis.cs.umass.edu> moss@cs.umass.edu (Eliot Moss
) writes:

   Our GNU M3 system is expected to support of TYPEOF operator that will return
 a
   data structure describing the type of the argument to TYPEOF. This would let
   you write browsers fairly easily. However, this feature is not a required pa
rt
   of M3, so would not necessarily work in other implementations.

I should have pointed out that I am describing functionality, not its
packaging. The type-of feature will be nicely tucked away in an interface, not
an extension to the language. In fact, I like Greg Nelson's idea that it
should be called Type.Of (i.e., Type is the interface for the type descriptor
stuff, and Of is a name declared therein that accepts a REFANY and returns a
type descriptor object for the referent).
--

		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


======================================================================== 51 ===
Date:    Sat, 25 Jan 92 07:58:05 PST
From:    msm@src.dec.com (Mark S. Manasse)
Subject: Re: Modula-3 difficulties

To make it harder to accidentally have opaque types do the wrong thing
in a TYPECASE statement, the language requires that the concrete revelation
of an opaque type be branded. 

Just REVEAL a = BRANDED OBJECT ... and all will be well.

Mark


======================================================================== 52 ===
Date:    26 Jan 92 00:08:45 GMT
From:    sharon@lcs.mit.edu (Sharon Perl)
Subject: Generics in SRC M3 2.0

The handling of generics in SRC Modula-3 v.2.0 seems to be undocumented magic.
Greg told me that if I put my generic interfaces in ".ig" files and generic
modules in ".mg" files it would work. It sort of works, except that m3make
doesn't seem to notice if I change a ".mg" file. Also, I can find nothing
in the m3 man page or release notes about ".ig" or ".mg" files.
Am I missing something?

Sharon


======================================================================== 53 ===
Date:    25 Jan 92 22:50:43 GMT
From:    patl@bodacia.Eng.Sun.COM (Pat Lashley [MtV NeWStech Eng.])
Subject: Porting 2.01 to a new OS

Once again, it looks like I might be able to squeeze out a little time to
work with Modula-3.  So, instead of writing something in m3, I decided to
build the latest compiler... :-)  I built a version for SPARC under SunOS
4.1.1 with no problems.  (Congratulations and hartfelt thanks to all involved
the the restructuring of the distribution - it is a major improvement over
the earlier releases.)

In a fit of insanity I decided that my next step should be to port it to
SVr4 ... err, SunOS5 ...  oops, I mean Solaris-2... :-)  The new layout
gives me warm feelings about how easy this probably is, but I could use
some concrete instructions on how to set up a cross-compiler, and how to
use it to build a native compiler for the new system.  (And which files/
directories I'm likely to have to touch.)

I'm also open to suggestion on what to call the target, since SPARC is
taken...



Thanks,
-Pat



---
PMLashley	plashley@Sun.COM    SunSoft:NeWS Tools & Services
	"I haven't lost my mind -- it's backed up on tape somewhere..."


======================================================================== 54 ===
Date:    26 Jan 92 05:44:27 GMT
From:    johnh@wheaton.EDU (John (Doc) Hayward)
Subject: Re: Three language changes I would like to see

In article <1992Jan24.190459.25994@newross.Princeton.EDU> nr@cs.Princeton.EDU w
rites:
>I don't know whether the language committee will consider any more
>changes, but here are three changes I would like to see.
...
Here is one which I would like to see.

The facility to declare in an interface module a READONLY set of variables.
    This would function much like the READONLY parameter in procedures and
    would guarentee that any module using these variables would only look
    at them.

    I know it is possible to write functions which return the values of 
    module variables not viewable in the interface which the module wants
    to protect from outside changes but this proposal would allow for easier
    coding on the part of the programmer and better code on the part of 
    the compiler.  
    
    An example might be the error variable for a set of procedures in a
    module which clients should be to view but not change.
johnh...
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=
UUCP: johnh@wheaton.uucp           telephone: (708) 752-5871 (office)
Mail: John Hayward Math/Computer Science Dept. Wheaton College Wheaton Il 60187
       Act justly, love mercy and walk humbly with your God. Micah 6:8b


======================================================================== 55 ===
Date:    27 Jan 92 14:21:31 GMT
From:    dagenais@vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: Object browser for inspection/debugging

> One problem is that in 2.0 the printprocs have gone away - 
> they were a considerable component in the large image sizes. 
...
> However, I have some plans to do this anyway as part of another project.
> If you would like to pursue this, I would be happy to help out 
> (especially with the lack of documentation on m3tk). On the latter issue 
> I can say that there is a 2.0 version of m3tk that will ship soon...

Thanks for the info. It is always enlightening to hear what projects are
going on. In fact it may be interesting to probe the newsgroup a few times
a year to know what is going on at DEC/SRC (Trestle, Libraries, SRC M3
2.X...) at GNU (GNU/M3 with persistent objects)and elsewhere.

For the browser i guess i will wait for things to get more stable, there is
no point in duplicating work. Even though it is not a "required component",
run-time information about types cannot be added easily as an "optional
library" on just any compiler. Thus, it would be nice if the DEC/SRC/M3 
and GNU/M3 could agree on such an interface.

In the mean time i will get back at what i am probably most useful at for
the moment: disseminating Modula 3 among colleagues and students.
--
---------------------------------------------------------------------

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

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


======================================================================== 56 ===
Date:    Mon, 27 Jan 92 10:15:38 PST
From:    <kalsow@src.dec.com>
Subject: Re: Exception semantics

I believe that most programmers ignore the potential bug.
Few exception handlers depend on the exact assignments done within
the TRY body and few C compilers are agressive enough to keep
variables in registers across procedure calls.  In the end, the
bug doesn't seem to bite.

Thanks for reading the documentation so carefully!

  - Bill Kalsow


======================================================================== 57 ===
Date:    Mon, 27 Jan 92 10:16:52 PST
From:    <kalsow@src.dec.com>
Subject: Re: Runtime errors

>  Another SRC Modula-3, 2.0, question.  How are "checked runtime errors"
>  reported?

We write a message on stderr and then crash.

  - Bill Kalsow


======================================================================== 58 ===
Date:    Mon, 27 Jan 1992 21:14:48 PST
From:    David Goldberg <goldberg@parc.xerox.com>
Subject: Re: Problems with Fmt interface

I also have been bothered by limitations in the Fmt interface for
printing REALs.
I'd like to float (ha, ha) the following proposal:

	David Goldberg
	goldberg@parc.xerox.com

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

I find the behavior of Fmt.Real hard to control using the current
parameters.  For example, if I want to print a number in Mix mode, but
in a form suitable as an M3 REAL literal (i.e. 34.0, not 34.), there's
no simple way to do that.  Or if I want to round to 4 places in Flo
mode, making 123456789 come out as 123400000, there's no simple way to
do that, either.  Here's an alternate proposal:
   
TYPE
      Style = {Sci, Flo, FloRnd}

Real(x: REAL;
     style: Style := FloRnd;
     maxFraction: CARDINAL := 6; (* max places right of decimal point *)
     minFraction: CARDINAL := 0; (* min places right of decimal point *)
     forcePt := FALSE;           (* always print decimal point *)
     roundDigits := 7;           (* for FloRnd mode *)
     shorten := FALSE;           (* use Sci if it would be shorter *)
);

The algorithm is
(1) For Style = Sci, use prevailing rounding mode to round to form
    x.xxxxEnn, with maxFraction digits right of decimal point.  If
    minFraction < maxFraction, then trim trailing zeros (if any),
    keeping at least minFraction digits right of the decimal point.
    If minFraction = 0 and all digits right of decimal point are zero,
    then forcePt controls whether there is a decimal point.  The
    parameter shorten is ignored.

(2) For Style = Flo, use prevailing rounding mode to round to
    xxxx.xxxxx (or .0000xxxx), with maxFraction digits right of
    decimal point.  Possibly trim trailing zeros, using minFraction,
    forcePt.  If shorten is TRUE, recompute with style := Sci, and use
    this result if it is shorter.
	
(3) For Style = FloatRnd, use prevailing rounding mode to convert to
    number of form xxxx.xxxxx with rndDigit significant digits and at
    least minFraction digits right of decimal place.  Apply forcePt
    as before.  The parameter maxFraction is not used.  If shorten is
    TRUE, recompute with style := Sci and maxFraction := roundDigits-1
    (to keep the same precision), and use this result if shorter.


Examples:

Real(987654321.0, Style.Sci)
   9.876543E9

Real(987654321.0, Style.Flo)
   987654321

Real(987654321.0, Style.Flo, minFraction := 1)
   987654321.0

Real(987654321.0, Style.Flo, forcePt := TRUE)
   987654321.

Real(987654321.0, Style.FloRnd)
   987654300

Real(987654321.0, Style.FloRnd, minFraction := 1)
   987654300.0

Real(.0000987654321, Style.FloRnd)
   .00009876543

Real(.000987654321, Style.FloRnd, shorten := TRUE)
   9.876543E-5


======================================================================== 59 ===
Date:    Mon, 27 Jan 92 16:56:02 PST
From:    <kalsow@src.dec.com>
Subject: Re: Reducing garbage collection overhead in SRC M3 1.6

Norman,

Thanks for the detailed information.

Here at SRC we're using a slightly newer version of RTHeap than
is available on gatekeeper.  (We'll remedy that problem soon.)
Our version exports the policy parameters of RTHeap as
variables that a programmer can set.  Here's the key pieces
of the allocator/collector that use those parameters:

    VAR activePages: INTEGER;
    (* the number of pages holding allocated objects *)

    VAR allocatedPages: INTEGER;
    (* the number of pages allocated to the heap ("from" + "to" spaces) *)

    VAR availPages == allocatedPages DIV 2.
    (* the number of pages in the current space *)

    PROCEDURE Alloc () =
        VAR neededPages := << # pages needed to satisfy current allocation >>
        IF <<there's enough free space in the current free page>> THEN
          << allocate the object from the current page >>
        ELSIF (activePages + neededPages <= availPages) THEN
          Collect (A * neededPages)
          << recursively call the allocator >>
        ELSE
          p := FindPages (neededPages)
          << allocate the object beginning at page p >>
        END;

    PROCEDURE Collect (neededPages) =
        << do the collection, adjusting activePages accordingly >>
        VAR freePages := availPages - activePages;
        VAR needed := MAX (recoveryRatio * availPages, minRecovery, neededPages
)
        IF (freePages < neededPages) THEN GrowHeap (neededPages) END;

    PROCEDURE FindPages (neededPages): Page =
        << search for a contiguous list of pages >>
        IF << there's no contiguous chunk that's big enough >> THEN
          GrowHeap (neededPages);
        END;
        << return the next free page >>

    PROCEDURE GrowHeap (neededPages) =
        VAR nPages := MAX (allocatedPages * growthRate, minIncrement,
                            B * neededPages)
        << extend the heap by nPages pages (split between "from"
           and "to" spaces) >>

    
And here's the settings of those parameters:

   version:          2.0        Norman's      SRC's latest
   A                  0            0                1
   B                  1            1                2
   recoveryRatio      0          1/gamma            0.3
   minRecovery       64           32              128         
   growthRate         0.2   gamma * %active - 1     0.3
   minIncrement      64           64              128

In SRC's latest version "recoveryRatio", "minRecovery",
"growthRate" and "minIncrement" are settable variables.

  - Bill Kalsow


======================================================================== 60 ===
Date:    Tue, 28 Jan 92 08:30:03 PST
From:    <kalsow@src.dec.com>
Subject: Re: Generics in SRC M3 2.0

You're right.   We forgot to document the file conventions 
and m3make rules for generics.

SRC's version of the 'm3' driver detects when a generic source
changes and recompiles the instantiations.

We'll ship the fixed documentation and driver asap.

  - Bill Kalsow


======================================================================== 61 ===
Date:    Tue, 28 Jan 1992 19:00:02 GMT
From:    nr@cs.Princeton.EDU ()
Subject: More about garbage collection

Bill,

This table gave me a misleading impression that SRC's latest garbage
collector is using Appel's heap growth algorithm (which is what I
implemented):

> And here's the settings of those parameters:
> 
>    version:          2.0        Norman's      SRC's latest
>    A                  0            0                1
>    B                  1            1                2
>    recoveryRatio      0          1/gamma0            0.3
>    minRecovery       64           32              128         
>    growthRate         0.2   gamma0 * %active - 1     0.3
>    minIncrement      64           64              128
> 
> In SRC's latest version "recoveryRatio", "minRecovery",
> "growthRate" and "minIncrement" are settable variables.

To recapitulate Appel's model, gamma is the ratio of heap size to live
data, and gamma0, the desired value of gamma, is the single settable
parameter.  The garbage collector knows the amount of live data (and
hence gamma) only right after a (major) collection.  Applications that
do lots of allocations can increase gamma0 to reduce GC overhead by
using more memory.  I have changed gamma to gamma0 in the table.


My algebra comes out different from yours:

	mine			src's latest

	heap size		allocatedPages
	live data		activePages (right after collection only)
	heap/2 - live		freePages
	heap/2			availPages
	gamma = heap/live	?

The criterion for deciding when the heap should grow is the same as
Appel's, in your units

	freePages < recoveryRatio * availPages

but in Appel's units

	heap size < live data * gamma0 

and these criteria are the same provided that

	gamma0 = 2 / (1 - recoveryRatio)
	recoveryRatio = 1 - (2 / gamma0)

which perversely works out the same as yours when gamma0 = 3!


On the other hand, when you do grow the heap, your increment size is

	allocatedPages * growthRate

so that the growth increment doesn't depend on the amount of live
data.  I'm not sure how much difference this makes since the decision
on whether to grow is made based on the amount of live data, but the
difference and the extra parameter seem gratuitous.

I'm troubled by a garbage collector which applies two different sets
of criteria to decide when to grow the heap. I'm troubled by a garbage
collector with six parameters, four of which are settable by users.
What criteria do I use to decide how to tune the collector for my
application?  If I naively set recoveryRatio too high and growthRate
too low, I'm going to get bitten.  What advantages does the
multiparameter model offer?  Wouldn't it be worthwhile trying to find
a simpler model?
-- 
Norman Ramsey
nr@princeton.edu


======================================================================== 62 ===
Date:    28 Jan 92 22:07:43 GMT
From:    rdubey@yoda.eecs.wsu.edu (Rakesh Dubey - grad student)
Subject: Problem in compiling with m3


The program Main.m3 in the directory shown below does not compile and I
get this intermittent error.
/tests/m3tests/ptests/p001
$ m3 Main.m3
(ccom): (null), line 1: ccom: Internal: build_tables out of memory

Sometimes it works all right, and sometimes it does not.
Is there something wrong with my implementation. This is on
a DEC3100.

Thanks a lot,
Rakesh
-- 
Rakesh Dubey
rdubey@yoda.eecs.wsu.edu


======================================================================== 63 ===
Date:    Wed, 29 Jan 1992 04:51:27 GMT
From:    andru@electron.LCS.MIT.EDU (Andrew Myers)
Subject: Placing dynamically created types in the heap


I'd like to be able to dynamically create "new types" which are
understood by the garbage collector. A brief scan through RTHeapRep
and RTTypeRep suggests that this is possible. However, the
Typecell.dataSize field prevents the creation of variable-sized
objects. It's also unclear to me how to add new Typecodes/Typecells to
the system (or even if it's possible).

Any thoughts on this? Thanks,

Andrew



======================================================================== 64 ===
Date:    Wed, 29 Jan 1992 09:34:20 PST
From:    dhinz@wbst845e.xerox.com (Daniel W. Hinz)
Subject: Does this indicate more than it says?


I'm new to m3 and have been just trying some things out. I was able to get all
the compilations to work until I tried to use an interface not in the core
interfaces. I get the following:

linden% m3 -v -o ex1 -lm3math example1.m3
/usr/local/lib/m3/m3compiler -D/usr/local/lib/m3/Xaw -D/usr/local/lib/m3/Xt
-D/usr/local/lib/m3/X11 -D/usr/local/lib/m3/io -D/usr/local/lib/m3/data 
-D/usr/local/lib/m3/math -D/usr/local/lib/m3/misc
-D/usr/local/lib/m3/ultrix-3-1 -D/usr/local/lib/m3/core -D. -w3 
-o 55412d372cf2000_m.c example1.m3 
/bin/cc -I/usr/local/lib/m3 -c 55412d372cf2000_m.c 
unlinking 55412d372cf2000_m.c ... done
nm -op 55412d372cf2000_m.o 
unlinking 55412d372cf2000_m.o ... done
interface Interval needed but not found

linden% 

This program uses Thread, Fmt, Wr, and Stdio without a problem. When I tried
adding Random or Interval I get the above message. The interface modules for
Random and Interval are in misc and math directories, respectively. I added
the -v option just for verification purposes.

If I add /usr/local/lib/m3/math/Interval.i3 to the command line the compiler
works but the linker of course complains about multiply defined symbols.

I'm running 1.6 on a Sparc2. I have a symbolic link from usr to local, which
have discounted because the core interfaces work on that path. The
installation went smoothly with no errors and no warnings.

Have I fallen prey to a common misunderstanding? Any help will be appreciated.
Thanks.

-dwh-


======================================================================== 65 ===
Date:    27 Jan 92 19:09:00 GMT
From:    srobyns@hpcupt3.cup.hp.com (Serge Robyns)
Subject: info on Modula3

Hi everybody,

I've read about modula2 several years ago, now I see that there is a modula3 
language which seems to support OO. I would like to have some info about
modula3. I'm currently a C programmer.

Can you send me:
	- References
	- Lex/Yacc definitions
	- Info where I can get one, free is liked most as I don't know if I
	  would use the language. Platforms (Mac, MSDOS, HP-UX)

Thanks in advance,

Serge Robyns (srobyns@hpcupt3.cup.hp.com)


======================================================================== 66 ===
Date:    Wed, 29 Jan 1992 17:57:12 GMT
From:    nr@cs.Princeton.EDU ()
Subject: Supporting fast lexical analysis in Modula-3

I've written an interpreter which spends 25% of its time in two
routines: UnsafeRd.FastGetChar and UnsafeWr.FastPutChar.  This is
happening during lexical analysis, mostly during scanning of
identifiers and string literals, e. g. roughly

  VAR token := TextWr.New();
      c : CHAR;
  BEGIN
    (* ... *)
    REPEAT (* read a name *)
      UnsafeWr.FastPutChar(token, c);
      c := UnsafeRd.FastGetChar(rd);
    UNTIL flags[c].stop;
    RETURN TextWr.ToText(token);
    (* ... *)
  END;

Lexical analysis is a common bottleneck in compilers, so others are
likely to encounter similar problems.  I would like to find a solution
that others can use.  I propose an extension to the reader abstraction
that will permit the use of some of the techniques described by
William Waite in ``The Cost of Lexical Analysis,'' Software---Practice
& Experience 16(5), 473--488 (May 1986).  These techniques

  (1) avoid copying characters out of the read buffer unless necessary
  (2) scan very quickly through common character sequences, like
      white space, identifiers, and string literals

To achieve (1) I suggest making it possible to ask a reader to
remember a subsequence of characters in its buffer, then produce them
later.  Most of the time the characters would be in the buffer and
could be produced quickly using SUBARRAY.  To achieve (2) I suggest a
procedure that scans through the reader looking for a ``stop
character.''  The implementation would use the unsafe features of
Modula-3 to construct a tight inner loop using pointers in registers.

Here are a proposed interface and a sample use of that interface.  
I would like comments.  Here is the interface, RdLex:

  INTERFACE RdLex;
  FROM Rd IMPORT T, Error, Failure, EndOfFile, Alerted;
  
    (*  Supports fast lexical analysis by reducing copying and
        by providing fast character search *)
  
  
     (*  Add to the reader abstraction the following two values:
  
          tokset(r)               a Boolean 
          tok(r)                  an integer in the range [0..cur(r)-1]
  
         If tokset(r) is TRUE, then r must ``remember'' the character
         sequence src(r)[tok(r)..cur(r)-1].  Seeking causes an error
         if tokset(r) is TRUE.
     *)
  
  PROCEDURE SetToken(r:T; offset:[-1..0]) RAISES {Error};
  
    (* IF cur(r) + offset < 0 THEN
         RAISE Error;
       ELSE
         tokset(r) := TRUE;
         tok(r) := cur(r) + offset;
       END;
     *)
  
  PROCEDURE ForgetToken(r:T) RAISES {};
  
    (* tokset(r) := FALSE; *)
  
  
  TYPE TokenClosure = 
         OBJECT METHODS apply(READONLY a: ARRAY OF CHAR) RAISES {} END;
  
  PROCEDURE GetToken(r:T; offset:[-1..0]; cl:TokenClosure):TokenClosure
          RAISES {Error};
  
    (* IF NOT tokset(r) OR cur(r)+offset < 0 THEN
         RAISE Error;
       ELSE
         tokset(r) := FALSE;
         cl.apply(SUBARRAY(src(r),tok(r),cur(r)+offset-tok(r)));
         RETURN cl;
       END;
     *)
  
  
  TYPE FlagSet = SET OF [0..7];
  
  PROCEDURE Search(r:T;
                   READONLY flags: ARRAY CHAR OF FlagSet;
                   stopflags: FlagSet;
                   sentinel:CHAR):CHAR
      RAISES {Error, Failure, EndOfFile, Alerted}; (* raises like GetChar *)
  
    (* IF stopflags * flags[sentinel] = FlagSet {} THEN
         RAISE Error;
       ELSE
         REPEAT
           c := GetC(r);
         UNTIL stopflags * flags[c] # FlagSet {};
         RETURN c;
       END;
  
       N. B. the purpose of the sentinel is to make it possible
             to implement the inner loop without having to check
             for overflow past the buffer.
    *)
  
  END RdLex.

I think the implementation of RdLex need not be too different from the
existing RdMove implementation.  It can certainly be made to work with
the existing class methods.


Here is an example for the use of these procedures, drawn loosely from
the lexical analyzer for my PostScript interpreter.  I have compiled
the example against the RdLex interface.  Atom.FromChars is a
procedure that looks up a sequence of characters in a ``unique string
table.''  If the sequence is already in the table, it returns an
Atom.T (containing a TEXT) that is already allocated.  Thus, in the
common case of reading an identifier that is already known, the
lexical analyzer doesn't do any allocation or any copying.



  MODULE SampleLex EXPORTS Main;
  IMPORT Atom, Rd, RdLex;
  
  VAR flags := ARRAY CHAR OF RdLex.FlagSet { RdLex.FlagSet {NonWhite}, .. };
  CONST NonWhite = 0;           (* set for non-white space characters *)
        StopCharacters = 1;     (* set for chars that end a name token *)
        StringSpecials = 2;     (* set for '(', ')', '\\' *)
  
  EXCEPTION Unmatched; (* unmatched ( or { in input *)
  
  PROCEDURE NextToken(rd:Rd.T) RAISES {Rd.EndOfFile, Unmatched} =
  VAR c : CHAR;
      depth : INTEGER;
      result : Atom.T;
  BEGIN
    c := RdLex.Search(rd, flags, RdLex.FlagSet {NonWhite}, 'x');
    CASE c OF
    | '0'..'9' => (* read and return a number *)
    | ')' => RAISE Unmatched;
    | '(' => RdLex.SetToken(rd,0);          (* read a string *)
             depth := 1;
             WHILE depth > 0 DO
               c := RdLex.Search(rd, flags, RdLex.FlagSet{StringSpecials},')');
               CASE c OF
               | '(' => INC(depth);
               | ')' => DEC(depth);
               | '\\' => (* RETURN SlowString(rd); -- ugly case! *)
               END;
             END;
  	   result := NARROW(RdLex.GetToken(rd, -1, atomcl), AtomClosure).a;
             (* RETURN AtomProperties.StringOf(result); *)
    ELSE (* read a name *)
      RdLex.SetToken(rd, -1);
      TRY EVAL RdLex.Search(rd, flags, RdLex.FlagSet {StopCharacters}, ' ');
          result := NARROW(RdLex.GetToken(rd, -1, atomcl), AtomClosure).a;
      EXCEPT Rd.EndOfFile =>
          result := NARROW(RdLex.GetToken(rd,  0, atomcl), AtomClosure).a;
      END;
      (* RETURN AtomProperties.NameOf(result); *)
    END;
  END NextToken;
                        
  TYPE AtomClosure = RdLex.TokenClosure OBJECT 
                                       a : Atom.T;
                                     METHODS (*OVERRIDES*)
                                       apply := SetAtom;
                                     END;
  
  VAR atomcl := NEW(AtomClosure);
  
  PROCEDURE SetAtom(cl:AtomClosure; READONLY a: ARRAY OF CHAR) RAISES {} =
  BEGIN cl.a := Atom.FromChars(a); END SetAtom;
  
  BEGIN 
    flags[' ']  := flags[' ']  - RdLex.FlagSet { NonWhite };
    flags['\n'] := flags['\n'] - RdLex.FlagSet { NonWhite };
    flags['\t'] := flags['\t'] - RdLex.FlagSet { NonWhite };
    flags['(']  := flags['(']  + RdLex.FlagSet { StringSpecials };
    flags[')']  := flags[')']  + RdLex.FlagSet { StringSpecials };
    flags['\\'] := flags['\\'] + RdLex.FlagSet { StringSpecials };
    (* and so on ... *)
  END SampleLex.
-- 
Norman Ramsey
nr@princeton.edu


======================================================================== 67 ===
Date:    29 Jan 92 14:24:46 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: Placing dynamically created types in the heap

In article <1992Jan29.045127.15647@mintaka.lcs.mit.edu>
andru@electron.LCS.MIT.EDU (Andrew Myers) writes:

   I'd like to be able to dynamically create "new types" which are
   understood by the garbage collector. A brief scan through RTHeapRep
   and RTTypeRep suggests that this is possible. However, the
   Typecell.dataSize field prevents the creation of variable-sized
   objects. It's also unclear to me how to add new Typecodes/Typecells to
   the system (or even if it's possible).

Umm, gee, how would they work w.r.t. TYPECASE and stuff like that? What is it
that you're *really* trying to do? Maybe we can give more hints. I'm also
interested because our GNU Modula-3 implementation does types in a different
way from the SRC system (but still compatible with the language spec).
--

		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


======================================================================== 68 ===
Date:    29 Jan 92 21:33:53 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: EXTENDED support coming?

In version 2.0, the floating type EXTENDED uses the same
representation as LONGREAL on the DS3100 (and maybe everywhere).  
I hope we will soon be able to take advantage of the EXTENDED type.
What are the plans?

On a related note, does anyone have software routines for the basic
math functions on IEEE extended types?

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.


======================================================================== 69 ===
Date:    30 Jan 92 07:08:19 GMT
From:    chased@rbbb.Eng.Sun.COM (David Chase)
Subject: Re: Placing dynamically created types in the heap

In article <1992Jan30.015730.2206@mintaka.lcs.mit.edu> andru@electron.LCS.MIT.E
DU (Andrew Myers) writes:
>I want to implement the runtime system for a new language. I have two
>choices:
>
>	- I manage my own heap, and write my own garbage collection.
>
>	- I insert language objects into the Modula-3 heap, and let
>	  Modula-3 handle the garbage collection.
>
>Is the second choice feasible?

Could be, but it means that you are depending upon the DEC M-3 GC not
changing in the future.  If all you want is GC, go nab a collector
from either Hans Boehm and Mark Weiser (of Xerox PARC) or Joel
Bartlett (of DEC-WRL) or from Daniel Edelson (was of UC Santa Cruz).

As for the question of adding types on the fly -- it's a semi-solved
problem, and the guys at SRC should know how to do it, because we've
discussed it in the past.  There was a recent letter in TOPLAS
detailing one method of answering the "is_subtype_of" question that I
think can be incrementally updated, and there is another method based
on an paper by Paul Dietz that uses pre and post-order traversal
numbers.  I think there was another semi-recent paper in either TOPLAS
or JACM on operations on lattices that might subsume this problem
(i.e., handle the multiple inheritance case). TYPECASE presents a bit
of a problem if you want to do concurrent updating of the data
structures.  An additional thing to explore would be the use of
Dietz-Sleator numbers for the pre and post order numbers.

David Chase
Sun


======================================================================== 70 ===
Date:    30 Jan 92 00:36:20 GMT
From:    woolsey@mri.uucp (Jeff Woolsey)
Subject: Re: Runtime errors

In article <9201271817.AA18601@jumbo.pa.dec.com> kalsow (Bill Kalsow) writes:
>>  Another SRC Modula-3, 2.0, question.  How are "checked runtime errors"
>>  reported?
>
>We write a message on stderr and then crash.

Yeah, but you still don't say where the error occurred.  Big fun
finding it in 10000 lines of code.

So I whipped up this kludge for 1.5, and finally converted it to 2.0
beta today (guess why).  It does the trick for SPARC.

Apply the diff, compile the .c module, and explicitly mention the .o on
the m3 command line when linking.  I don't have the disk space or
patience to add it to libm3.a (and don't know what effect it would have
on libm3.ax).

*** lib/m3/M3RuntimeDecls.h	Wed Jan 29 16:12:39 1992
--- lib/m3/M3RuntimeDecls.h%	Wed Jan 29 16:10:18 1992
***************
*** 266,277 ****
  
  #define _NARROW(e,tc) if (!_ISSUBTYPE(_TYPECODE(e),tc)) _NARROWFAULT
  
! #define _ASSERTFAULT        _jlwRuntime__AssertFault (__FILE__, __LINE__)
! #define _RETURNFAULT        _jlwRuntime__ReturnFault (__FILE__, __LINE__)
! #define _CASEFAULT          _jlwRuntime__CaseFault (__FILE__, __LINE__)
! #define _TYPECASEFAULT      _jlwRuntime__TypecaseFault (__FILE__, __LINE__)
! #define _RANGEFAULT         _jlwRuntime__RangeFault (__FILE__, __LINE__)
! #define _NARROWFAULT        _jlwRuntime__NarrowFault (__FILE__, __LINE__)
  
  #define _CVTIF(x)                ((float) x)
  #define _CVTLF(x)                ((float) x)
--- 266,277 ----
  
  #define _NARROW(e,tc) if (!_ISSUBTYPE(_TYPECODE(e),tc)) _NARROWFAULT
  
! #define _ASSERTFAULT        RTMisc__AssertFault ()
! #define _RETURNFAULT        RTMisc__ReturnFault ()
! #define _CASEFAULT          RTMisc__CaseFault ()
! #define _TYPECASEFAULT      RTMisc__TypecaseFault ()
! #define _RANGEFAULT         RTMisc__RangeFault ()
! #define _NARROWFAULT        RTMisc__NarrowFault ()
  
  #define _CVTIF(x)                ((float) x)
  #define _CVTLF(x)                ((float) x)


=========
jlwrun.c:
=========

#include	<stdio.h>

void _jlwRuntime__AssertFault (file, line) char *file; int line;
{
	fprintf(stderr, "\n\"%s\", line %d: ", file, line);
	RTMisc__AssertFault ();
}

void _jlwRuntime__ReturnFault (file, line) char *file; int line;
{
	fprintf(stderr, "\n\"%s\", line %d: ", file, line);
	RTMisc__ReturnFault ();
}

void _jlwRuntime__CaseFault (file, line) char *file; int line;
{
	fprintf(stderr, "\n\"%s\", line %d: ", file, line);
	RTMisc__CaseFault ();
}

void _jlwRuntime__TypecaseFault (file, line) char *file; int line;
{
	fprintf(stderr, "\n\"%s\", line %d: ", file, line);
	RTMisc__TypecaseFault ();
}

void _jlwRuntime__RangeFault (file, line) char *file; int line;
{
	fprintf(stderr, "\n\"%s\", line %d: ", file, line);
	RTMisc__RangeFault ();
}

void _jlwRuntime__NarrowFault (file, line) char *file; int line;
{
	fprintf(stderr, "\n\"%s\", line %d: ", file, line);
	RTMisc__NarrowFault ();
}

-- 
-- 
Jeff Woolsey			800 950 5554	woolsey@mri.COM
Microtec Research, Inc.	     +1 408 980 1300	woolsey@netcom.COM
Nothing like a three-address mailer....		woolsey@folderol.UUCP


======================================================================== 71 ===
Date:    Thu, 30 Jan 92 01:19:57 PST
From:    muller@src.dec.com (Eric Muller)
Subject: Re: Problem in compiling with m3

In article <1992Jan28.220743.16543@serval.net.wsu.edu>, rdubey@yoda.eecs.wsu.ed
u (Rakesh Dubey - grad student) writes:
> 
> The program Main.m3 in the directory shown below does not compile and I
> get this intermittent error.
> /tests/m3tests/ptests/p001
> $ m3 Main.m3
> (ccom): (null), line 1: ccom: Internal: build_tables out of memory
> 
> Sometimes it works all right, and sometimes it does not.
> Is there something wrong with my implementation. This is on
> a DEC3100.

We tend to have large programs around here, and the C code that comes
out of the compiler can be very large.  To make the C compiler happy, we
add to increase the size of some internal tables, by passing some
arguments to CC.  If you look in your config file, you will see:

PASS1 = @$(CC)@-G@4@-Wf,-XNp200000@-Wf,-XNd150000@

What is most likely to happens is that your system does not always
have enough memory (physical+swap) to accomodate the allocation of
such large tables.  As this depend on the current load of the machine, you
get intermittent errors.  We haven't tried to adjust the parameters to
the smalllest values that will work for the distributed programs; you
can try to do that.  The simplest is give commands of the form:

m3 -Y1@cc@-G@4@-Wf,-XNp200000@-Wf,-XNd150000@ ...

changing the 200000 and the 150000.  There is a little problem
however.  If you overflow the table, the result is not predictable:
the objects produced by the C compiler can be plain wrong, and you
don't get any warning (if course, if the C compiler had been written
in Modula-3...).

If you don't use Trestle, I believe that you can use
the default values of cc, by giving commands of the form:

m3 -Y1@cc@-G@4@ ...

-- 
Eric.



======================================================================== 72 ===
Date:    Thu, 30 Jan 92 01:33:48 PST
From:    muller@src.dec.com (Eric Muller)
Subject: Re: Porting 2.01 to a new OS

In article <ko3qe3INN8n5@exodus.Eng.Sun.COM>, patl@bodacia.Eng.Sun.COM (Pat Las
hley [MtV NeWStech Eng.]) writes:

> In a fit of insanity I decided that my next step should be to port it to
> SVr4 ... err, SunOS5 ...  oops, I mean Solaris-2... :-)  The new layout
> gives me warm feelings about how easy this probably is, but I could use
> some concrete instructions on how to set up a cross-compiler, and how to
> use it to build a native compiler for the new system.  (And which files/
> directories I'm likely to have to touch.)
> 
> I'm also open to suggestion on what to call the target, since SPARC is
> taken...

I am putting the final touches to a new release, that will make ports
much easier.  It's almost there.  Really.  I took some notes for what
needs to be done; they are below.  

The first part lists the places in the sources that have machine
dependencies today; if the system you are porting too is sort of bsd,
it is very likely that this is enough.  This certainly needs to be
rewritten, but you may start to investigate the amount of work you
will have to do.

I haven't included the second part that give all the details about
building the cross-compiler and cross-compiling, as it may change, and
you don't need them right now since you don't have the properly
organized sources and tools.  When the release will be made you will
have to start from that release.

-- 
Eric.




===============================================================================
Adapt the libm3 sources to your target system:

Some the Modula-3 code (as well as very little pieces of C) are
architecture dependant. Of course, it may be that some code we thought
to be machine independant will turn to have to be changed for your NEW
architecture, so we cannot guarentee that the list of things to fix
below is exhaustive.  In general, look at what is done for the other
machines, and find the most similar as a starting point.

Go in the libm3 archive.  Here are the components that are machine dependant.

Csupport/src.  Add a directory NEW, and put in it:
 - m3makefile: to describe the contents of the directory
 - M3Machine.h: is included in every C file generated by the Modula-3
   compiler.
 - dtoa.c: this piece of code just configures generic/dtoa.base; look at
   that file for the things to configure.
 - float.h: you need this file if your system does not provide one.  You
   can build it using a program called enquire, which can be found on the 
   net.  We included a copy of it in boot archives, in the directory misc.

C/src. Add a directory NEW, and put in it:
 - m3makefile
 - Csetjmp.i3: describes the interface to the setjmp and longjmp routines.
               Be careful to get the size of the jmp_buf right.
 - Cstdio.i3: describes the stdio stuff


thread/src. Add a directory NEW, and put in it:
 - m3makefile
 - WildJmp.i3: this interface provide functions that are similar to
   setjmp and longjmp, but these functions should not impose any
   restriction on what is possible.  For example, the VAX version
   requires that longjmp call actually pop the stack (remember that
   "longjmp botch" message ?), which is not good enough for our use of
   Wildjmp.  Instead the VAX version provides its own assembly code to
   do the work.  The IBMR2 is similar, but here we included the object
   in the distribution and use it rather than the source (and the
   m3makefile reflects that).  The DS3100 version is the simplest,
   because there are no restrictions on the uses of setjmp.

runtime/src.  The dependency described there is for the benefit of the
   garbage collector.  At the beginning of a collection, the collector
   must find all the roots, that is all the heap objects that are
   pointed to from outside the heap itself.  The stacks contain such
   pointers, and the collector scans them to find roots.  However, the
   collector does not know the full structure of the stacks (frames,
   argument lists and so on); rather, it just looks at the values that
   are there and make conservative decisions by interpreting these
   values as possible pointers.  For each stack, the collector
   initializes a pointer P to the bottom of the stack; then it
   repeatedly tries to interpret the bits pointed by P as a pointer in
   the heap, marks the root if the interpretation is succesful and
   advances P.  The question is by how much P should be advanced; if
   all entries in the stack are aligned at a n-bytes boundary, it is
   sufficient to increment P by n bytes; a smaller value would be an
   overkill.  We have found that some machines require n to be 2, and
   that 4 is enough for others.  If one of these two values is
   good for you, just remember it.  Otherwise, create a subdirectory
   StackInc-<n>, fill it like StackInc-2 (don't forget to modify
   StackInc.i3 with your value of n), and remember your value of n.

float/src.  Add a new directory NEW, and copy into it the files of the
  subdirectory MODEL.  The routines in these modules provides access
  the floating point control (set exceptions and so on).  The version
  in MODEL is a template, and most of the routines will fail (because
  of an <*ASSERT FALSE*>) if executed.  The DS3100 directory is an
  example of implementation for an IEEE machine, the VAX directory is
  an example for non-IEEE machines.  It is not essential that you 
  implement the proper procedures right now: the compiler and the driver
  do not depend on these interfaces (more precisely, the template in 
  MODEL is good enough).  But you will have to take care of them at
  some point.

random/src.  This also contains code that depends on the
  representation of floating point numbers.  There are three models in
  there: IEE-be (big endian), IEEE-le (little endian), VAX.  If one of
  these is good for you, just remember which one it is; otherwise,
  create your own.

unix/src.  That one is big.  The interfaces in this component provide
  access to the routines of section 2 and of section 3 (read, close,
  etc). Not everything is needed to boot the driver and the compiler.
  You may want to use the version for another achitecture that is not
  too distant from yours and fix it as you discover problems.
  Remember the name of the one you want to use for the bootstrap
  purpose, or of the copy you made for your system.
  
Finally, you need to fix the src/m3makefile to include a bunch
of lines of the form:
	#ifdef TARGET_NEW
	...
	#endif
similar to the ones that are already there, using the
version of StackInc you have selected or created (same for unix, ...).


======================================================================== 73 ===
Date:    Wed, 29 Jan 92 23:06:19 PST
From:    muller@src.dec.com (Eric Muller)
Subject: Re: Runtime errors

In article <1992Jan30.003620.8177@mri.uucp>, woolsey@mri.uucp (Jeff Woolsey) wr
ites:
> In article <9201271817.AA18601@jumbo.pa.dec.com> kalsow (Bill Kalsow) writes:
> >>  Another SRC Modula-3, 2.0, question.  How are "checked runtime errors"
> >>  reported?
> >
> >We write a message on stderr and then crash.
> 
> Yeah, but you still don't say where the error occurred.  Big fun
> finding it in 10000 lines of code.
> 
> So I whipped up this kludge for 1.5, and finally converted it to 2.0
> beta today (guess why).  It does the trick for SPARC.

Funny.  I have written similar code for 1.6; the main difference was
that the compiler generated the appropriate strings (as Text.Ts)
instead of "__FILE__" and "__LINE__" and the Modula-3 runtime could
handle that.

I liked it very much, because more often that not, this is enough info
to find out what the problem is.  However, it makes the code
significantly bigger (the string was unique in each file, of course)
and was therefore removed.

What I do today is just to run the program under debug and wait for
the crash to occur to see where the failed check is.

-- 
Eric.



======================================================================== 74 ===
Date:    Thu, 30 Jan 92 01:04:42 PST
From:    muller@src.dec.com (Eric Muller)
Subject: Re: Does this indicate more than it says?

In article <9201291734.AA11531@linden>, dhinz@wbst845e.xerox.com (Daniel W. Hin
z) writes:

> linden% m3 -v -o ex1 -lm3math example1.m3
> ...
> interface Interval needed but not found
> ...
> Have I fallen prey to a common misunderstanding? Any help will be 
> appreciated.

Yes.  The order of arguments is important (in 1.6; the rules are
slightly different for 2.0), just as they are for C programs.  In that
case, the library m3math is searched for resolutions of undefined
symbols before example1.m3 is linked in.  At that point, nobody asked
for "Interval", so it is not loaded from the library.  Then
example1.m3 comes along, and Interval is now needed, but there is no
longer anybody to provide it.

Try:
	m3 -o ex1 example1.m3 -lm3math

-- 
Eric.



======================================================================== 75 ===
Date:    Thu, 30 Jan 1992 01:57:30 GMT
From:    andru@electron.LCS.MIT.EDU (Andrew Myers)
Subject: Re: Placing dynamically created types in the heap

I want to implement the runtime system for a new language. I have two
choices:

	- I manage my own heap, and write my own garbage collection.

	- I insert language objects into the Modula-3 heap, and let
	  Modula-3 handle the garbage collection.

Is the second choice feasible?

It seems to require that I be able to specify new types to the Modula-3
runtime, since it is through types that the SRC-2.0 garbage collector decides
where the references are. I'm not interested in doing a TYPECASE on these
types, obviously; just in allowing GC to grok them.

Any more thoughts?


======================================================================== 76 ===
Date:    Thu, 30 Jan 92 01:09:55 PST
From:    muller@src.dec.com (Eric Muller)
Subject: Re: info on Modula3

In article <47090001@hpcupt3.cup.hp.com>, srobyns@hpcupt3.cup.hp.com (Serge Rob
yns) writes:

> Can you send me:
> 	- References

@techreport     (m3-BN89,
author          = "Mark R. Brown and Greg Nelson",
title           = "{IO} Streams: Abstract Types, Real Programs",
number          = "53",
type		= "SRC report",
institution     = "System Research Center, Digital Equipment Corporation",
address         = "Palo Alto",
month		= nov,
year            = 1989,
howtoget	= "On paper, by sending a mail to src-report@src.dec.com.",
what		= "Shows how to use objects in a real program. Also 
		   defines the de facto standard input/output functions."
)

@article	(m3-Har90,
author		= "Sam Harbison",
title		= "Modula-3",
journal		= "Byte",
volume		= 15,
number		= 12,
pages		= "385--392",
month		= nov,
year		= 1990, 
what		= "A survey article."
)

@book		(m3-Nel91,
title		= "System Programming with Modula-3",
editor		= "Greg Nelson",
publisher	= "Prentice Hall",
year		= 1991
)

The last one contains the definition of the language.  Sam, is your
book on the shelves now ?

> 	- Lex/Yacc definitions

See below.

> 	- Info where I can get one, free is liked most as I don't know if I
> 	  would use the language. Platforms (Mac, MSDOS, HP-UX)

Look on gatekeeper.dec.com, in pub/DEC/Modula-3; there is a version
for HP-UX.  The distribution includes a pretty-printer which uses a
lex/yacc parser.  The compiler has its own recursive descent parser.

-- 
Eric.



======================================================================== 77 ===
Date:    Thu, 30 Jan 92 16:13:43 +0100
From:    Piet van Oostrum <piet@cs.ruu.nl>
Subject: Re: info on Modula3

>>>>> muller@src.dec.com (Eric Muller) (EM) writes:

EM> Look on gatekeeper.dec.com, in pub/DEC/Modula-3; there is a version
EM> for HP-UX.  The distribution includes a pretty-printer which uses a
EM> lex/yacc parser.  The compiler has its own recursive descent parser.

The HP-UX version has a couple of smaal problems. I have solved most but
not all (lack of time being the biggest reason).


======================================================================== 78 ===
Date:    Thu, 30 Jan 92 08:38:09 -0800
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: Re: info on Modula3

Eric,

Please add my book to your bibliography database.  Also, does the IO
Streams tech report have anything in it that the chapter in SPwM3 does
not? I noticed that you apparently dropped the Modula-3 report from your
list, presumably because it is now out of date.

Sam "Looking out for #1" Harbison



======================================================================== 79 ===
Date:    30 Jan 92 17:42:20 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: Re: Runtime errors

In article <1992Jan29.230619.27814@src.dec.com> Eric Muller writes:
>...
>Funny.  I have written similar code for 1.6; the main difference was
>that the compiler generated the appropriate strings (as Text.Ts)
>instead of "__FILE__" and "__LINE__" and the Modula-3 runtime could
>handle that.
>
>I liked it very much, because more often that not, this is enough info
>to find out what the problem is.  However, it makes the code
>significantly bigger (the string was unique in each file, of course)
>and was therefore removed.
>...

I urge you to revert to the 1.6 behavior as the default, so that checked
run-time errors print a message with the location of the error.

Most programmers trip over run-time errors.  It is a specific benefit of
Modula-3 that such errors are caught and do not have to be tracked down with a
debugger. However, under the current behavior you DO have to use a debugger to
locate the errors. Seems wrong to me.

It may be reasonable to add a compile-time option to "minimize" the runtime
checking overhead in specific cases.  Experience indicates some people will
even ask for an option to eliminate checking entirely, although the wisdom of
that choice is debatable.

Sam


======================================================================== 80 ===
Date:    30 Jan 92 14:14:41 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: info on Modula3

Just to add to Eric's info, the Revised Report on Modula-3 is available on
gatekeeper.dec.com in pub/DEC/Modula-3. It is a little out of date w.r.t. a
few topics (the Nelson book is the best reference on the language definition).
In addition to the SRC implementation, we are working on a GNU implementation.
We don't use lex; we do use bison (the GNU yacc clone) and could send you our
bison defs if you *really* need them ....			Eliot Moss
--

		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


======================================================================== 81 ===
Date:    29 Jan 92 20:03:13 GMT
From:    johnh@wheaton.EDU (John (Doc) Hayward)
Subject: m3make documentation missing?

In section 5.3 of SRC Modula-3 version 2.0 it talks about m3make.  This is
a great facility for which my students can easily write m3makefiles.  I could
not find the manual page which it mentioned for more details.  Did I miss it
or was it left out?   If someone has a copy could they e-mail it to me.
Thanks in advance.
johnh...
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=
UUCP: johnh@wheaton.uucp           telephone: (708) 752-5871 (office)
Mail: John Hayward Math/Computer Science Dept. Wheaton College Wheaton Il 60187
       Act justly, love mercy and walk humbly with your God. Micah 6:8b


======================================================================== 82 ===
Date:    30 Jan 92 14:20:05 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: Problem in compiling with m3

Perhaps gcc would be more friendly than cc??
--

		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


======================================================================== 83 ===
Date:    30 Jan 92 14:22:47 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: Supporting fast lexical analysis in Modula-3

I guess my reaction is that if you want a buffer oriented interface (which is
what fast lexical analysis seems to need) rather than a character oriented
one, then build/use it, rather than hacking up a character oriented interface
to act like a buffer oriented one.
--

		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


======================================================================== 84 ===
Date:    30 Jan 92 14:18:42 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: Placing dynamically created types in the heap

Something else you might be interested in is the UMass garbage collector
toolkit we have under development. It is specifically designed to help
language implementors supply gc. It is based on copying collection and
requires accurate location of all pointers in the stack, globals, and
registers, and assumes that, given a pointer to (the base of) a heap object,
you can find the pointers inside it. But it supplies a lot of generational
collection mechanism in return for that. Perhaps you should correspond with me
privately for more details ...				Eliot Moss
--

		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


======================================================================== 85 ===
Date:    Thu, 30 Jan 92 12:18:07 PST
From:    muller@src.dec.com (Eric Muller)
Subject: Re: info on Modula3

In article <MOSS.92Jan30091441@ibis.cs.umass.edu>, moss@cs.umass.edu (Eliot Mos
s) writes:
> Just to add to Eric's info, the Revised Report on Modula-3 is available on
> gatekeeper.dec.com in pub/DEC/Modula-3. It is a little out of date w.r.t. a
> few topics (the Nelson book is the best reference on the language definition)

If you are using 2.x, it's enough out of date to get you in trouble.
Besides, Greg's book is *really* worth the $25 or so; the other
chapters are also very good.

Here is a small update of the bibliographic info:

@book		(m3-Nel91,
title		= "System Programming with Modula-3",
editor		= "Greg Nelson",
publisher	= "Prentice Hall",
isbn		= "0-13-590464-1",
year		= 1991,
what		= "The bible for Modula-3.  Includes the language
                   reference manual and papers on the I/O library,
                   threads, and the Trestle window system."
)

@book		(m3-Har92,
title		= "Modula-3",
author		= "Samuel P. Harbison",
publisher	= "Prentice Hall",
isbn		= "0-13-596396-6",
year		= 1992,
what		= "A complete Modula-3 testbook covering the full
                   language, with examples and exercises.  Includes a
                   style manual and a user's guide for SRC Modula-3."
)


-- 
Eric.



======================================================================== 86 ===
Date:    Thu, 30 Jan 92 12:00:02 PST
From:    muller@src.dec.com (Eric Muller)
Subject: Re: m3make documentation missing?

In article <1992Jan29.200313.6581@wheaton.EDU>, johnh@wheaton.EDU (John (Doc) H
ayward) writes:
> In section 5.3 of SRC Modula-3 version 2.0 it talks about m3make.  This is
> a great facility for which my students can easily write m3makefiles.  I could
> not find the manual page which it mentioned for more details.  Did I miss it
> or was it left out?   If someone has a copy could they e-mail it to me.

Here is what we have today.  It's bad, but it's there.  We hope it
will be more useful than confusing.  Some the words may apply to SRC
only.  We are rewritting it.

Eric.



                                                                      M3MAKE(1)

NAME
     m3make - Modula-3 make

SYNTAX
     m3make [-s] target ...

DESCRIPTION

     m3make is a slightly enhanced version of plain make(1).  The
     primary benefit of m3make is that the operational description
     found in most makefiles is replaced by a more declarative one.
     The result is that makefiles are smaller, simpler, and more
     portable.

     m3make is essentially a combination of cpp and make; don't be afraid,
     the interface to the combination is usually simpler than that of make.
     When started, m3make looks for a file named 'm3makefile' in the current
     directory.  This file describes what goes into a particular piece of
     the system, but not how to construct it.  The operational aspects
     of the system are confined to templates that are configured when
     SRC Modula-3 is installed (see the m3make package).  The language
     recognized by m3make is described below.

     To process an m3makefile, just type 'm3make'.  It accepts the same
     options as make.

     By default, m3make defines the following targets:

        all       constructs this package's program or library
        install   installs the result in a public directory
        tidy      deletes temporary files
        scratch   deletes all derived files

     The default target is 'all'.

     If you want additional things done with these targets, you can extend
     them with make's double-colon rules.  For example, suppose that
     the file lex.yy.c is a derived file that you want to be able to
     'scratch', add the following to your m3makefile:

             scratch::  ;  /bin/rm -f lex.yy.c

     Note the two colons after the target name. 

     m3makefiles follow the C convention for comments; that is, they are
     enclosed by /* and */.  A comment can cross line boundaries.

     Note that the full power of make is available in m3make since
     the last step of m3make is to invoke make.  Most m3makefiles
     don't need this extra generality.

     If you have trouble with m3make, it may help to examine the actual
     input to make.  The final file created by m3make and passed to
     make is named .makefile.

Modula-3 packages

     SRC Modula-3 is distributed as a set of packages.  A 'package' is a
     directory of files including an m3makefile, README, COPYRIGHT,
     and usually a collection of Modula-3 source files.  Packages are located
     in a fixed location in the file system that is determined at configuration
     time (e.g. /proj/m3/pkg). There are three basic types of packages:
     source, program, and library.  A 'source package' contains a collection
     of Modula-3 sources, it builds nothing.  A 'program package' constructs
     a single executable program (an 'a.out' file) by compiling and linking the
     contents of a set of source packages.  Similarly, a 'library package'
     constructs a single library (a '.a' file) from a set of source packages.

Source packages

     The m3makefile for a source package simply lists the pieces of source
     that are to be included in programs or libraries that name this package.
     The following entries are allowed in a source package's m3makefile:

        interface(X)       the file 'X.i3 contains an interface.

        implementation(X)  the file 'X.m3' contains a module.

        module(X)          the files 'X.i3' and 'X.m3' contain an interface
                           and its implementation.

        generic_interface(X)  the file 'X.ig' conatins a generic interface.

        generic_implementation(X)  the file 'X.mg' contains a generic module.

        generic_module(X)  the files 'X.ig' and 'X.mg' contain a generic
                           interface and its generic implementation

        h_source(X)        the file 'X.h' contains a C include file.

        c_source(X)        the file 'X.c' contains a C module.

        s_source(X)        the file 'X.s' contains an assembly module.

        pgm_source(X)      the file 'X' contains compilable source (eg. .ic,
                           .mc, .is or .ms files).

        source(X)          the file 'X' contains non-compilable source.

        source_dir(D)      recursively include the sources named in the
                           m3makefile in directory D.

        package(P)         include the sources named in package P.

     The capitalized forms of interface, module, generic_interface,
     generic_implementation, generic_module, and h_source (i.e. Interface,
     Module, Generic_interface, Generic_implementation, Generic_module, and
     H_source) are also allowed.  They mean the same as their lower-case
     counterparts, but they cause their interfaces (X.i3, X.ig, X.mg and X.h)
     to be exported to the public include repository
     (e.g. /proj/m3/pub.mips).

Program packages

     The m3makefile for a program package names the sources needed to build
     the program with any of the source package entries named above. A program
     package may also include any of the following:

        program(X)        constructs an executable program named 'X'
                          from the given sources.

        Program(X)        like 'program' but also exports the contructed
                          program to the public /bin directory.

        import_lib(X)     include '-lX' in the final link command.

     Exactly one 'program' or 'Program' entry must be present in 
     a program package's m3makefile.
 
     In addition to the entries above, a program or library package may
     define any of the following {\tt make} variables:

         name             default          meaning
         -------------    --------------   -----------------------------
         M3               m3               the Modula-3 compiler
         M3FLAGS          -w1 -make -why   compilation flags
         M3OPT            -g               debug/optimization flags
         M3DEFPATH                         search path for imported interfaces
         M3LIBPATH                         search path for libraries

     See the m3(1) man page for full details on the flags it recognizes.

Library packages

     The m3makefile for a library package names the sources to be included
     in the library with any of the source package entries named above.
     A library package may also include either one of the following:

        library(X)     constructs a library named 'X.a' and its
                       linker file 'X.ax' from the given sources.

        Library(X)     like 'library' but also exports the library
                       and its linker file to the public /lib directory.

     Exactly one 'library' or 'Library' entry must be present in
     a library package's m3makefile.

Machine dependencies

     Generally, each version of a machine-dependent program or library is
     described by a separate m3makefile that references the particular
     source packages needed for that version.  Machine-dependencies may
     also be encoded with cpp #if's and #ifdef's.  For example, the piece
     of the base library's m3makefile that includes the random number
     generator looks like this:

         package(random/generic)
         #ifdef TARGET_VAX
         package(random/VAX)
         #endif
         #ifdef TARGET_DS3100
         package(random/IEEE-le)
         #endif
         #ifdef TARGET_SPARC
         package(random/IEEE-be)
         #endif

Examples

     The following packages from /proj/m3/pkg should be good starting
     points for writing your own m3makefiles:

        text           - a source package that implements Text.T's
        sx             - a small, self-contained library package
        libm3          - a larger library package that imports
                              several source packages
        ui/apps        - a custom makefile to build several test programs
        compiler/mips  - a large program (the compiler itself)

See Also
     m3(1)  make(1)  cpp(1)

Author Of Object
     Bill Kalsow

Author Of Documentation
     Bill Kalsow


======================================================================== 87 ===
Date:    Thu, 30 Jan 92 12:11:34 PST
From:    muller@src.dec.com (Eric Muller)
Subject: Re: Problem in compiling with m3

In article <MOSS.92Jan30092005@ibis.cs.umass.edu>, moss@cs.umass.edu (Eliot Mos
s) writes:
> Perhaps gcc would be more friendly than cc??

May be.  It certainly is on VAX Ultrix 3.1, where cc is broken with
respect to the void type.  But you need the -traditional flag, that
is:

PASS1 = @gcc@-traditional@

in the config file.  Otherwise, gcc defines some additional keywords
(non KR and non ANSI C) that conflict with some variable names.

-- 
Eric.



======================================================================== 88 ===
Date:    Thu, 30 Jan 1992 18:01:24 GMT
From:    nr@elan (Norman Ramsey)
Subject: Re: Runtime errors

In article <1992Jan29.230619.27814@src.dec.com> muller@src.dec.com
(Eric Muller) writes: 
>Funny.  I have written similar code for 1.6; the main difference was
>that the compiler generated the appropriate strings (as Text.Ts)
>instead of "__FILE__" and "__LINE__" and the Modula-3 runtime could
>handle that.
>
>I liked it very much, because more often that not, this is enough info
>to find out what the problem is.  However, it makes the code
>significantly bigger (the string was unique in each file, of course)
 ^^^^^^^^^^^^^
>and was therefore removed.

How much bigger?  I'm just a curmudgeonly old 1.6 user, but I want
*more* information from the failure messages (e.g., please tell me
which procedures RAISES list won't pass my exception), not less.
Those file names and line numbers are incredibly useful for me to find
errors in my 10,000-line program.  I cannot believe that putting one
instance of a TEXT with the source file name increases the code size
by more than 1%.  Seems to me like there must be better ways to reduce
code size.

>What I do today is just to run the program under debug and wait for
>the crash to occur to see where the failed check is.

One can't always run under the debugger.  One can't always duplicate
in inputs of a 20-minute run that ends in failure.  If one is, like
me, stupid enough to write concurrent programs that don't synchronize
properly, one can't ever duplicate the sequence of context switches
caused by the virtual timer interrupt.

If you absolutely can't afford to print source file names and line
numbers, alter the macros to call abort() inline, and provide a signal
handler that catches the abort and writes the PC on stderr.



======================================================================== 89 ===
Date:    Fri, 31 Jan 1992 00:03:08 GMT
From:    contrct2@cheops.qld.tne.oz.au (Contract_2_login)
Subject: Porting SRC to SYSV4_386

	I've been hammering away (at my previous job, using a MIPS 6280 as a
cross compiler) trying to port this to a 386 running V.4. Alas, no matter
what combination of setjmp or sigsetjmp I try, I always come up with a
runtime error when switching threads. I am strongly considering rewriting
Thread.m3 to use the getcontext/swapcontext co-routineing interface in V.4.
(PS location 0 in the jmpbuf was the only one that did not give me an
assertion failure about SP & oldSP being equal, it bombed later on with a
possible NIL dereference). Using the {get,swap}context stuff would make that
part portable across all V.4 implementations. I've used it when handtranslating
Modula2 to C as a substitute for TRANSFER.

	Anybody else doing this?


	Cheers

	Stephen Hocking
-- 
------------------------------------------------------------------------------
"We are but truffles before the pigs of fate..."
                   Telecom does not know I'm saying this.
	Stephen Hocking			contrct2@cheops.qld.tne.oz.au


======================================================================== 90 ===
Date:    Fri, 31 Jan 92 01:10:18 -0600
From:    johnh%rachel@uunet.UU.NET (John (Doc) Hayward)
Subject: Re: m3make documentation missing?


Thanks so much.  This is much better than looking at how it was used and
trying to abstract the rules.

Both me and my Data Structures students thank you.
johnh...
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=
UUCP: johnh@wheaton.uucp           telephone: (708) 752-5871 (office)
Mail: John Hayward Math/Computer Science Dept. Wheaton College Wheaton Il 60187
       Act justly, love mercy and walk humbly with your God. Micah 6:8b


======================================================================== 91 ===
Date:    Fri, 31 Jan 1992 03:16:20 GMT
From:    nr@atomic (Norman Ramsey)
Subject: Re: Problems with Fmt interface


I like David Goldberg's proposal, although I'm not sure I understand
it precisely enough to be able to implement it :-).  It would be
pleasant to have an interface that would format a floating-point
number with just enough decimal digits to recover the original
floating point value on input, but no more (a la Clinger/Steele).
But that's probably an orthogonal issue...


======================================================================== 92 ===
Date:    31 Jan 92 03:20:37 GMT
From:    nr@atomic (Norman Ramsey)
Subject: Re: Supporting fast lexical analysis in Modula-3

In article <MOSS.92Jan30092247@ibis.cs.umass.edu> moss@cs.umass.edu writes:
>I guess my reaction is that if you want a buffer oriented interface (which is
>what fast lexical analysis seems to need) rather than a character oriented
>one, then build/use it, rather than hacking up a character oriented interface
>to act like a buffer oriented one.

I don't have any objection to a buffer-oriented interface, and it
would get rid of the grotesque closure in my interface.  I do want
an interface that will apply to all readers, not to a specialized
abstraction usable only for lexical analysis, and I want fast (unsafe)
scanning hidden behind a safe interface.  I will think about a
buffer-oriented interface and see if I can come up with a clean one.


======================================================================== 93 ===
Date:    Fri, 31 Jan 92 11:09:25 PST
From:    muller@src.dec.com (Eric Muller)
Subject: Re: Problems with Fmt interface

In article <1992Jan31.031620.28010@newross.Princeton.EDU>, nr@atomic (Norman Ra
msey) writes:
> 
> It would be
> pleasant to have an interface that would format a floating-point
> number with just enough decimal digits to recover the original
> floating point value on input, but no more (a la Clinger/Steele).
> But that's probably an orthogonal issue...

Should not be too difficult.  The current distribution uses dtoa.c
from David M. Gay from AT&T Bell Labs, which does just that.  We have
in the pipe the rewritting of this code in Modula-3, so that we can
avoid the unnecessary allocations that take place now.  Also, we would
have a better integration with the Convert/Fmt interface.

-- 
Eric.



======================================================================== 94 ===
Date:    31 Jan 92 16:20:55 GMT
From:    johnh@wheaton.EDU (John (Doc) Hayward)
Subject: bug fix request for m3pp

Dear People,
  I and my students are just starting to use the pretty printer tool m3pp.
It appears that in addition to "closing delimiters" that the last identifier
and possible semicolon can cause the pretty-printer to exceed the margin
limit.  The example below with an offeset of 4 will not fit in an 80 column
display unless the margin is set to 67 or less.  This is more than
"a little lower" than what I want.
...
     -margin n
           Set the margin to n. The margin is the maximum width
           of an output line.  The pretty-printer occasionally
           exceeds this maximum, so it's usually wise to set it a
           little lower than you want.  If this option is not
           specified, a margin of 75 is used.
...
BUGS
     The pretty-printer sometimes exceeds the margin limits due
     to details of the formatting algorithm.  The text that
     exceeds the limit usually consists of closing delimiters,
     such as right parens and right brackets.  Setting the margin
     a little lower than you want usually does the trick.

Last modified on Mon Dec 23 10:36:17 PST 1991 by muller
     modified on Mon Nov 25 18:14:36 PST 1991 by meehan
...
Example:

INTERFACE StackMod;
    TYPE
	StackType = T2 OBJECT 
	    METHODS 
		BrandStack(Brand : INTEGER)
		    RAISES {StackAlreadyBranded} := MBrandStack
	    END;

END StackMod.

m3pp -o 4 -m 68 or larger causes MBrandStack to extend past 80 while
m3pp -o 4 -m 67 or smaller does not cause MBrandStack to extend past column 80

It seems from the comments that the correction may not be trivial but it would
be nice to have this fixed.
johnh...
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=
UUCP: johnh@wheaton.uucp           telephone: (708) 752-5871 (office)
Mail: John Hayward Math/Computer Science Dept. Wheaton College Wheaton Il 60187
       Act justly, love mercy and walk humbly with your God. Micah 6:8b
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=
UUCP: johnh@wheaton.uucp           telephone: (708) 752-5871 (office)
Mail: John Hayward Math/Computer Science Dept. Wheaton College Wheaton Il 60187
       Act justly, love mercy and walk humbly with your God. Micah 6:8b


