======================================================================== 1 ===
Date:    Fri, 1 Nov 91 08:27:50 PST
From:    <kalsow@src.dec.com>
Subject: troubles with opaque types

Attached below is a short exchange between Bert Laverman (laverman@cs.rug.nl)
and myself on the problems of compiling opaque types.

  - Bill Kalsow

---- Laverman -> Kalsow ------------------------------------------------------

  I am a PhD student at Groningen University, the Netherlands, and
currently working on a small paper concerning generic types, and the
(im)possibilities for doing static checks on their usage. I contacted
Sam Harbison in connection with the Modula-3 report, since I thought I
had reasoned out a way for the example Queue routines (pp 14-15) to be
compiled without needing runtime type checks. This was ofcourse based on
a small extension, namely that of type parameters.
  I will not go into that right now (though ever at your service if you
are interested ;-)). A second part of my message to him was a request
for related subjects for my research. One of his answers concerned the
link-time resolving of opaque types. He gave me your email addresses for
reference.
  I have ordered the book (SPwM3), but it may take a while before it arrives.
Could you give me a more specific description of the problem involved.
Since you are involved in writing a compiler for Modula-3, perhaps you can
give me a more detailed description of the problem.

---- Kalsow -> Laverman ------------------------------------------------------

The general problem with opaque types is that the full information
needed to generate high quality code isn't available until the 
entire program is available (e.g. link time).

For example:

   INTEFACE A;
   TYPE T <: ROOT;
   END A.

   INTERFACE B;
   IMPORT A;
   TYPE T <: A.T OBJECT x: INTEGER END;
   END B.

A client of B.T knows that there's an integer-valued 'x' field,
but doesn't know it's offset.

   INTERFACE C;
   IMPORT A;
   TYPE T <: ROOT;
   REVEAL A.T = T BRANDED OBJECT y: INTEGER END;
   END C.

And even a client of C who sees the "full" revelation of A.T
doesn't know the offsets since they depend on C.T.

Finally, the truth might be hidden in an arbitrary piece of
the system:

   MODULE FooBar;
   IMPORT C;
   REVEAL C.T = BRANDED OBJECT z: INTEGER END;
   ....

The kinds of information that a compiler would like at compile
time, but aren't available until later include:

   1) offsets of fields & methods
   2) the total size of the object
   3) the default values of the fields & methods
   4) which fields must be traced by the garbage collector
   5) the full inheritance hierarchy

I hope this helps.

---- Laverman -> Kalsow ------------------------------------------------------

I would like to continue on your example.
I tried some m3 minimal tests with SRC m3. Appearently
circular dependecies are not allowed. I don't know if this
is the same for the current m3 standard (book hasn't arrived
yet), but at least this means that a compilation order can
be determined. SRC-m3 seems to translate the interfaces separately
from the modules, and I suppose this is the cause of the problem.

Such a separate compilation serves a relaxation in the development
order, but I wonder if actual _real_ compilation is needed at that
stage. A simple checker (say up to, but not including intermediate
code generation) would suffice. For the real compilation the
dependency graph can be followed, in which case the interface itself
is at most needed for - again - error checks. The exported information
can maybe be generated from the _module_, rather than the interface.
In this way all the wanted bits of information can be supplied to
those importing the module. A strategy might be to generate this
export file directly after all the declarations have been processed,
using the interface as a guide for what information is needed.

A way of looking at it might be to merge the interface with the
module, using a special notation for those items that need exporting.
When thinking about that situation, the automatic generation of a
detailed export file comes as a natural consequence. There is no
reason to suddenly discard the implementation details when you're only
dropping textual details.

Then again, since I only now start on this, there may be something
I overlooked. Please attack me (verbally, please ;-)) at will.

---- Kalsow -> Laverman ------------------------------------------------------

I'm not sure I understand your message, but let me try to answer
anyway.

Modula-3 does not allow cycles in the import graph of interfaces.
Modula-3 does allow some recursions in declarations.
SRC Modula-3 compiles interfaces.

Yes, if you defer the "_real_ compilation" until all the interfaces
and modules are present, the problems I mentioned are easy.  I think
I said as much:

   The general problem with opaque types is that the full information
   needed to generate high quality code isn't available until the
   entire program is available.

Yes, separating the interfaces and implementations relaxes the
dependencies in compilation order.   This is not just a convenience.
In large systems developed concurrently by many programmers
it's a necessity.  Ask anyone writing software for the phone
company, aerospace industry or military complex.

Both Oberon and Eiffel merge the interface and implementation.
Eiffel at least has a tool to extract the interface.

Note that Modula-3 does not require a 1-1 correspondence between
interfaces and implementations.   An interface may be implemented
by more than one module and a module may implement parts of more
than one interface.  In this context merging is more troublesome,
but probably still possible.

The problems with opaque types are not solved by merging interfaces
and implementations.  The full revelation for an opaque type
exported by an interface A is not required to be in any of the
modules that implement A, although it usually is.  Modula-3 requires
only that every opaque type have a full revelation somewhere in the
program.


======================================================================== 2 ===
Date:    Fri, 1 Nov 91 14:56:21 PST
From:    muller@src.dec.com (Eric Muller)
Subject: Modula-3 Frequently Asked Questions (FAQ)

[ Last modified on Fri Nov  1 14:55:38 PST 1991 by muller ]


			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.



======================================================================== 3 ===
Date:    Fri, 1 Nov 91 15:08:01 PST
From:    muller@src.dec.com (Eric Muller)
Subject: archive of comp.lang.modula3

The archive of the messages sent to comp.lang.modula3 in September and
October 1991 are now available in

    gatekeeper.dec.com:pub/DEC/Modula-3/comp.lang.modula3/91-{09,10}.Z

Enjoy,
Eric.



======================================================================== 4 ===
Date:    4 Nov 91 14:05:01 GMT
From:    collberg@dna.lth.se (Christian S. Collberg)
Subject: Re: troubles with opaque types

<Discussion about problems compiling opaque types deleted>

I am in the process of writing up my thesis which describes an
experimental modular language (Zuse) and its implementation.
Basically, Zuse is Modula[23]/Ada-like but allows several levels of 
information hiding. In order to support this the implementation 
employs intermediate code linking. Currently there is a Zuse 
compiler, a sequential "paster" (intermediate code linker),
and a distributed paster which runs on a network of Sun-3:s.

The following rather lengthy blurb gives an informal description
of the language and its implementation. If someone is interested
I can send a copy of a preliminary version of a more detailed paper
which has been submitted for publication. I will email if you can
handle a compressed, uuencoded, postscript file. 

Regards,
Christian

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


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

In Zuse there are three ways to export a type, constant, or procedure:
Concrete export, semi-abstract export, and abstract export. A concrete
type, for example, reveals its entire realization in the specification
part of the exporting module, whereas an abstract type defers the realization
to the implementation unit. A semi-abstract type reveals some of its
realization in the specification and defers the rest to the implementation.
Similarly, a concrete procedure reveals its body and inline-status 
in the specification, whereas an abstract procedure hides these in the
implementation. A semi-abstract procedure hides its code but reveals
whether it is inline or not.


Concrete export
---------------

The Zuse type-system includes all the types of Modula-2 (equivalence,
subrange, enumeration, record, array, procedure, set, and pointer types),
an object type similar to the one found in Modula-3, and a UNIQUE type
similar to Ada's NEW type.

An object type comes in four parts: an optional super type (preceded by 
the keyword 'WITH'), a sequence of fields (the first set of brackets),
a sequence of methods (second set of brackets), and a sequence of method
overrides (third set of brackets). Constants may be scalar or structured.
Procedures may be inline. 

Concrete export is indicated by the symbol '=='. Here are some examples:

       SPECIFICATION Concrete;
           TYPE     RangeT   == RANGE INTEGER [0..20];  
           TYPE     SetT     == SET S;        
           TYPE     EnumT    == ENUM [blue, green]; 
           TYPE     RecordT  == RECORD [a, b : INTEGER];
           TYPE     ArrayT   == ARRAY CHAR OF INTEGER;
           TYPE     PointerT == REF RecordT;
           TYPE     ProcT    == (a : EnumT; b : REAL);
           TYPE     FunT     == (a : EnumT; b : REAL) RETURN CHAR;
           TYPE     EquivT   == ArrayT;
           TYPE     UniqueT  == UNIQUE INTEGER;

           TYPE     ObjectT  == OBJECT
                                   [a : INTEGER; x : CHAR]
                                   [p : (x : INTEGER) RETURN INTEGER := Proc1]
                                   [ ];

           TYPE     SubT     == WITH ObjectT OBJECT
                                   [r : REAL]
                                   [v : (x : REAL) RETURN REAL := Proc2]
                                   [p                          := Proc3];

           CONSTANT C1 : INTEGER == 10;
           CONSTANT C2 : RecordT == RECORD [a := 5; b := 6];

           PROCEDURE Proc1 : (T : ObjectT; a : INTEGER) RETURN INTEGER ==
           BEGIN ... END Proc1;

           PROCEDURE Proc2 : (T : SubT; a : REAL) RETURN REAL ==
           BEGIN ... END Proc2;

           PROCEDURE Proc3 : (T : ObjectT; a : INTEGER) RETURN INTEGER ==
           BEGIN ... END Proc3;

           INLINE PROCEDURE P : (a : INTEGER) == BEGIN ... END P;
       END Concrete.

       IMPLEMENTATION Concrete;
       END Concrete.
 

Abstract export
--------------- 

Abstract export is indicated by the symbol '='. The realization of
an abstract item is declared using the '+=' symbol. There are no restrictions
on the realization of an abstract type. The type of an abstract constant
may be either abstract or concrete. Abstract procedures hide their
body as well as their inline status. Examples:

       SPECIFICATION Abstract;
          (* An abstract type: *)
          TYPE     T = ;      
           
          (* An abstract constant of an abstract type: *)
          CONSTANT D : T = ;    

          (* An abstract constant of a concrete type: *)
          CONSTANT C : INTEGER = ;    

          (* An abstract procedure: *)
          PROCEDURE P : (a : INTEGER) =  
       END Abstract.

       IMPLEMENTATION Abstract;
          TYPE     T     += RECORD [a, b : INTEGER];
          CONSTANT D : T += RECORD [a :=10; b := 5];
                          (*   OR   *)
          TYPE     T     += INTEGER;
          CONSTANT D : T += 6;
                          (*   OR   *)
          TYPE     T     += ARRAY CARDINAL [0..100] OF CHAR;
          CONSTANT D : T += ARRAY [[0]="h"; [1]="i"; [2]="!"];

          CONSTANT C : INTEGER += 100;    

          PROCEDURE P : (a : INTEGER) += BEGIN ... END P;
                          (*   OR   *)
          INLINE PROCEDURE P : (a : INTEGER) += BEGIN ... END P;
       END Abstract.
  

Semi-abstract export:
---------------------

Zuse supports semi-abstract constants and procedures, and two kinds of
semi-abstract types. The realization of a semi-abstract item comes in
two parts: the visible part which is given in the specification unit,
and the hidden part which is deferred to the implementation unit. 

Semi-abstract types come in two flavors: semi-hidden and extensible. A 
semi-hidden type reveals its type-class in the specification unit and 
must be redeclared in the implementation. An extensible type, on the
other hand, reveals part of its realization in the specification and may
be extended in the implementation. 

There are four semi-hidden types: hidden pointer, subrange, object,
and enumerable types. A hidden pointer type (which is equivalent to
Modula-2's and Mesa's opaque type and Ada's deferred access type) may
only be realized by a pointer or address type. 
A hidden subrange type reveals its type in the specification unit
but defers its range to the implementation. 
A hidden object type (similar to Modula-3's opaque object type) must
be realized as an object type.
A hidden enumerable type may be realized by any ordinal type, 
i.e. by any of the built-in enumerable types (integer, character, 
boolean, etc), by enumeration types, or by subranges of these types. 
Examples:

       SPECIFICATION SemiHidden;
           TYPE     S = RANGE INTEGER;       (* Hidden subrange type *)
           TYPE     E = <>;                  (* Hidden enumerable type  *)
           TYPE     P = REF;                 (* Hidden pointer type *)
           TYPE     O = OBJECT;              (* Hidden object type *)
       END SemiHidden.

       IMPLEMENTATION SemiHidden;
           IMPORT SYSTEM;
           TYPE     S += RANGE INTEGER [10 .. 20];

           (* Any of the following implementations of E are possible: *)
           TYPE     E += INTEGER;              
           TYPE     E += CHAR;              
           TYPE     E += ENUM [mon, tue, wed, thu, fir, sat, sun];             
 
           TYPE     E += RANGE INTEGER [0..10];      
        
           TYPE     P += REF RECORD [a, b : REAL];  
           TYPE     P += SYSTEM`ADDRESS;

           TYPE     O += OBJECT [a : INTEGER] [] [];
       END SemiHidden.

An importer of SemiHidden can, for example, declare arrays with 
SemiHidden`E as an index type without any knowledge of how E is
realized:

             VARIABLE A : ARRAY CHAR, SemiHidden`E OF INTEGER;
             VARIABLE S : SET SemiHidden`E;


There are four extensible types: extensible record, enumeration, object,
and subrange types. An extensible record may reveal some fields in the
specification unit and may extend these with additional fields in the
implementation unit. Similarly, an implementation unit may add identifiers
to an extensible enumeration type, or widen the range of an extensible
subrange type. The extensible record type is similar to Oberon-1's public
projection type, only in Zuse it is not necessary to reveal the maximum size
of the realization in the specification unit of the exporting module. 

The fields, methods, method initializations, method overrides, and the
super type of an extensible object type may all either be revealed
or hidden. Note, however, an object may be given a super type either in
the specification or the implementation part of a module, but not
both. Furthermore, a method  may only be initialized in the specification
or the implementation, but not both.

The value of Zuse structured constants may be arbitrarily divided between
the specification and implementation units. The type of an extensible
constant may itself be extensible or concrete. 

        SPECIFICATION Extension;
           (* An extensible record type and a constant of this type. *)
           TYPE     T     = RECORD [a : INTEGER]; 
           CONSTANT D : T = RECORD [a := 10]; 

           (* A concrete record type and an extensible constant of this type. *
)
           TYPE     R     == RECORD [b : INTEGER; c : CHAR]; 
           CONSTANT C : R =  RECORD [b := 10]; 

           (* Extensible subrange type *)
           TYPE     S = RANGE INTEGER [0..10];  

           (* Extensible object type *)
           TYPE     O = OBJECT
                           [a : INTEGER] 
                           [p : (x : CHAR) RETURN INTEGER]
                           [];

           (* Extensible enumeration type *)
           TYPE     E = ENUM [red, blue, green];              
       END Extension.

       IMPLEMENTATION Extension;
           IMPORT SemiHidden;

           (* T now has both fields a and b *)
           TYPE     T     += RECORD [b : REAL]; 
           CONSTANT D : T += RECORD [b := 6.3]; 

           CONSTANT C : R +=  RECORD [c := "x"]; 

           (* S will really go up to 300 although a client *)
           (* may only use the values 0..10.               *)
           TYPE     S += RANGE INTEGER [0..300];  

           (* O now has all the fields and methods of SemiHidden`O, *)
           (* the fields a and b, and the methods p and q. p is     *)
           (* initialized to Proc2 and q to Proc1.                  *)
           TYPE     O += WITH SemiHidden`O OBJECT
                           [b : REAL] 
                           [q : (x : INTEGER) RETURN CHAR := Proc1]
                           [p :=  Proc2];

           (* E has one hidden value -- yellow -- in addition to the   *)
           (* public values red, blue, and green.                      *)
           TYPE     E += ENUM [yellow];              
       END Extension.

A semi-abstract procedure is one whose body is hidden but whose inline
status is revealed. Examples:

       SPECIFICATION SemiProc;
          INLINE     PROCEDURE P : (a : INTEGER) =  

          NOT INLINE PROCEDURE Q : (a : INTEGER) =  
       END SemiProc.

       IMPLEMENTATION SemiProc;
          INLINE PROCEDURE P : (a : INTEGER) += BEGIN ... END P;

          PROCEDURE Q : (a : INTEGER) += BEGIN ... END Q;
       END SemiProc.


Type protection
----------------  

In Zuse an exported type may be coupled with a protection clause which
lists the operations a particular importer may perform on objects of 
the type. Examples of operations which may be part of a protection
clause are assignment, component selection, and type coercion. All Zuse
types may be protected, including abstract- and semi-abstract types,
allowing for very fine grained control over the way a client of a module
may manipulate the module's exported items. Although types are the only
items which may receive an explicit protection, other exported items
(variables, constants, and procedures) may be implicitly protected by
protecting the items's type.  
   
       SPECIFICATION Protection;
            (* A protected abstract type. Only modules M and N may   *)
            (* manipulate objects of type Abstract, and the only     *)
            (* operation available to M and N is assignment.         *)
            TYPE Abstract = {(M,N):{:=, =:}};

            (* Assignment, addition, subtraction, and test for       *)
            (* equality are the only operations available on objects *)
            (* of type Address. "*:" indicates that all modules may  *)
            (* import and use the type.                              *)
            TYPE Address == {*:{:=,=:,+,-,=}} UNIQUE CARDINAL;

            (* All clients may assign and read variables of type     *)
            (* Open, but the field b is not accessible for           *)
            (* manipulation.                                         *)
            TYPE  Open == {*:{:=,=:}} RECORD [b : REAL]; 

            (* Variables of type Extensible are not assignable. The  *)
            (* field b is  accessible for manipulation, whereas a can*)
            (* only be read, not assigned to.                        *)
            TYPE Extensible = {*:{.,=:}} RECORD [a : {=:} CHAR; b : REAL];

            (* A readonly variable. *)
            VARIABLE V : {*:{=:}} CARDINAL;        
       END Protection.

       IMPLEMENTATION Protection;
           (* The exporting module is given permission to    *)
           (* access the fields of Abstract and to perform   *)
           (* type coercions involving Abstract.             *)
           TYPE Abstract  += {{., <<>>}} RECORD [a : INTEGER; b : REAL]; 

           (* The exporting module is given permission to    *)
           (* access the fields of type Open.                *)
           TYPE Open {{.}};

           TYPE Extensible  += {{., <<>>}} RECORD [a : INTEGER]; 
       END Protection.
     

Implementation
--------------

The Zuse translating system consists of a compiler and a paster,
a high-level linker. The Zuse compiler performs the same tasks as a 
traditional compiler, checking syntactic and static semantic correctness
of the input program and generating code for the target machine. The one
difference is that the compiler may defer some of the static semantic 
checking and some of the code generation to the paster. We list some 
of the circumstances under which such deferral will be necessary:
   * The compiler will not always know the size of a type which is defined
     in terms of imported abstract or semi-abstract types or constants.
     Hence it will be unable to generate (optimal) code for any 
     routine which allocates or references a variable of such a type.
   * The compiler cannot generate code for a call to 
     an imported abstract or inline semi-abstract procedure.
   * The compiler cannot always check whether the declaration of
     an abstract type, constant, or inline procedure which is
     defined in terms of imported abstract items is part of an 
     illegal recursive declaration.
   * The compiler cannot check the legality of a constant range 
     (as used in the label-section of a case-statement or in the 
     declaration of a subrange type) if either of the bounds is defined
     in terms of an abstract constant.

The Zuse compiler does not generate code for procedures which contain
references to unknown quantities. Such quantities include calls to imported
inline procedures, the sizes of imported abstract types, the values of 
imported abstract constants, etc. Procedures which reference unknown 
quantities are instead kept in their intermediate code form and code
generation is deferred to the pasting stage. Static semantic checks which
cannot be resolved during compilation, allocation of global variables of
unknown size, and creation of method templates for object types are also
left to the paster.

There currently exists two pasters, a sequential (the s-paster), and a 
distributed (d-paster). The d-paster achieves faster link times than 
the s-paster by distributing the work (chiefly inline expansion and code
generation) over a network of workstations. I am also working on an
incremental (i-paster) and a hierarchical (h-paster) paster. The i-paster
will speed up linking by modifying the result of the previous link 
instead of relinking the entire program. The h-paster will be able to
combine a set of modules into a library which can take part in later links.

The current implementation runs on and produces code for Sun-3 workstations.
 
-------------------------------------------------------------------------------
-

-- 

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


======================================================================== 5 ===
Date:    4 Nov 91 19:20:41 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: Call for articles, M3 News #2

I am beginning to put together issue #2 of the Modula-3 News, with
focus items on Teaching Modula-3 and on SRC Modula-3 2.0. If you have
any Modula-3 experiences you'd like to share, or if you would like to
hear about some particular topic, drop me a note. Please include your
phone number, in case I need verification or more information.

By the way, I now have 367 people on the Modula-3 mailing list. Many
don't have net access and therefore don't follow this newsgroup. 
66% are in the USA. Here is the breakdown by country.

Australia   10       Japan           1
Austria	     1       New Zealand     1
Belgium      1       Norway          1
Brazil       2       P.R.China       1
Bulgaria     1       Portugal        1
Canada      15       St. Lucia       1
Denmark      4       Scotland        1
England     29       South Africa    2
Finland      1       Sweden          3
France       7       Switzerland     6
Germany     16       The Netherlands 8
Hong Kong    2       USA           244
Ireland      2       USSR            1
Italy        4       Yugoslavia      1

Are you there? You are if you got Modula-3 News #1 from me or if you
contacted me to get on the list. If not, drop me a note with your
postal address. The text-only version of the newsletter will be posted
on gatekeeper.dec.com, but I've ordered an Apple OneScanner and I
might just go crazy in the printed version of Issue 2...

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.


======================================================================== 6 ===
Date:    Mon, 04 Nov 91 21:45:11 -0800
From:    Paul A Vixie <vixie@src.dec.com>
Subject: SRC M3 1.6 question: Time.Pause() a no-op?

this program prints "+pause+" followed by "-pause-" with no delay.

MODULE Main;

IMPORT Stdio, Wr, Time;

BEGIN
        LOOP
                Wr.PutText(Stdio.stdout, "+pause+\n");
                Wr.Flush(Stdio.stdout);
                Time.Pause(22);
                Wr.PutText(Stdio.stdout, "-pause-\n");
                Wr.Flush(Stdio.stdout);
        END;
END Main.


======================================================================== 7 ===
Date:    Mon, 04 Nov 91 22:59:01 -0800
From:    Paul A Vixie <vixie@src.dec.com>
Subject: SRC M3 1.6 stupid question

my ears are burning.  microseconds.  it says so right in the .i3 file.

thanks, mark.


======================================================================== 8 ===
Date:    6 Nov 91 01:21:57 GMT
From:    ehrlich@bucknell.edu (david ehrlich `92)
Subject: Oberon Question

I am looking for some sample programs to test an Oberon compiler.
If you have any short Oberon sources which are fairly representative
of the language, I would appreciate them.  I am not able to 
monitor this newsgroup, so please send them e-mail.

			Thanks,
			   David

----------------------------------------------------------------------
David Ehrlich		|  All comments are my own -- subject to 
Box C-0888		|  verification, clarification, reiteration,  
Bucknell University	|  and quite possibly, complete denial.  
Lewisburg, PA  17837	|
717-523-4294		|  Ehrlich auf Deutsch == Honest
----------------------------------------------------------------------


======================================================================== 9 ===
Date:    Thu, 7 Nov 1991 06:03:55 GMT
From:    luket@michelangelo.ee.adfa.oz.au (Luke Tarantello)
Subject: problem accessing supplied libraries...

I recently compiled m3 1.6 on a SPARC without any problems other than an 
inability to access any libraries other than the one in the core directory 
(libm3core.a is it's name I think). For example, if I import Math into a 
module the following occurs :

m3 -? -o program  RealPolar.mo Fourier.io Fourier.mo
pass0 = /usr/local/lib/m3/m3compiler
pass0 options =
defpath = /usr/local/lib/m3/Xaw /usr/local/lib/m3/Xt /usr/local/lib/m3/X11 
/usr/
local/lib/m3/io /usr/local/lib/m3/data /usr/local/lib/m3/math 
/usr/local/lib/m3/
misc /usr/local/lib/m3/ultrix-3-1 /usr/local/lib/m3/core .
pass1 = /bin/cc
incl  = /usr/local/lib/m3
pass1 options =
pass2         = /bin/cc
pass2 options =
pass3         = nm -op
pass3 options =
lib path      = /usr/local/lib/m3/Xaw /usr/local/lib/m3/Xt 
/usr/local/lib/m3/X11
 /usr/local/lib/m3/io /usr/local/lib/m3/data /usr/local/lib/m3/math 
/usr/local/l
ib/m3/misc /usr/local/lib/m3/ultrix-3-1 /usr/local/lib/m3/core
interface Math needed but not found

Notice that the path (/usr/local/lib/m3/math) is correct and that the 
syntax check phase finds Math.i3 as it does not complain, but that pass 3 
seems to fall over.

Should I be setting some compiler switch? Once this problem is solved I 
will be using the X libraries; will I have to set any compiler switches 
then?

Thanks

luke


======================================================================== 10 ===
Date:    Thu, 7 Nov 91 11:40:14 PST
From:    muller@src.dec.com (Eric Muller)
Subject: Re: problem accessing supplied libraries...

In article <1991Nov7.060355.17333@sserve.cc.adfa.oz.au>, luket@michelangelo.ee.
adfa.oz.au (Luke Tarantello) writes:
> I recently compiled m3 1.6 on a SPARC without any problems other than an 
> inability to access any libraries other than the one in the core directory 
> (libm3core.a is it's name I think). For example, if I import Math into a 
> module the following occurs :
> 
> m3 -? -o program  RealPolar.mo Fourier.io Fourier.mo
> ...
> interface Math needed but not found
> 
> Notice that the path (/usr/local/lib/m3/math) is correct and that the 
> syntax check phase finds Math.i3 as it does not complain, but that pass 3 
> seems to fall over.

The message "interface Math needed but not found" is indeed a bit
confusing.  Here is what happens: the driver (hence the compiler)
knows about the location of all the source interfaces of all libraries
(cf. "defpath = ...").  So the compiler does not complain when
compiling "IMPORT Math;".  The driver also knows the locations of all
the libraries.  However, the driver will not link your program will
all the libraries as this would be too expensive; you have to
explicitly mention the ones you need, using the -l option.  The only
libraries that will linked automatically in your program are the core
library, the "real" math librarie and the "real" C librarie (i.e.
there is an implicit -lm3core -lm -lc added to your link command)

If you compile with:

	m3 -o program  RealPolar.mo Fourier.io Fourier.mo -lm3math

you should be the desired result.

The same is true for the X11R4 binding libraries and the X11R4
libraries: you need (some of) the switches:

	-lm3Xaw -lm3Xt -lm3X11 -lXaw -lXt -lX11

You will also need some -Ldir switches if the Xaw, Xt and X11
libraries are not on the standard search path of ld; e.g.:

        -lm3Xaw -lm3Xt -lm3X11 -L/usr/lib/X11 -lXaw -lXt -lX11


-- 
Eric.



======================================================================== 11 ===
Date:    8 Nov 91 10:15:42 GMT
From:    usatoday@daimi.aau.dk (Peter Dalsgaard)
Subject: Oberon on Amiga ??

Hello !

I know that Oberon exists on the Amiga, but is it an english version,
is there more than 1 Oberon compiler for the Amiga ?, and how good is
it ?.

Any answers will be greatly appreciated

--
   *** Peter Dalsgaard               ***  
   *** usatoday@daimi.aau.dk         *** 
   *** University of Aarhus, Denmark ***
   


======================================================================== 12 ===
Date:    Fri, 8 Nov 91 16:51:19 GMT
From:    deyhle@peanuts.name.fmi.uni-passau.de 
Subject: Need help on installation of SRC Modula3


I trie to install SRC Modula-3 1.6 on a SPARC-SUN or a SUN3.
Following the installation procedure I copy util/config.dist-SPARC
to util/config. I set PREFIX to my home-directory and then call
make system. But I allways get an error. So could someone please
mail me what s going wrong:

>  $ make system
>  ---
>  --- <<< stuff without errors deleted >>>
>  ---
>  --- ultrix-3-1 starting on Fri Nov 8 16:48:50 MET 1991
>  ------ os starting on Fri Nov 8 16:48:52 MET 1991
>  .ROOT/system/driver/m3.local -D../Interfaces -g -c Unix.i3
>  M3 runtime error: Segmentation violation - possible attempt to
   dereference NIL
>  Program .ROOT/system/compiler/m3compiler got fatal signal 3.
>  *** Error code 1
>  make: Fatal error: Command failed for target `Unix.io'
>  Current working directory
   xxx/Modula-3/dist-1.6/libs/ultrix-3-1/os
>  .ROOT/util/imake: Exit code 1.  Stop.
>  *** Error code 1
>  make: Fatal error: Command failed for target `all'
>  Current working directory
   xxx/Modula-3/dist-1.6/libs/ultrix-3-1
>  .ROOT/util/imake: Exit code 1.  Stop.
>  *** Error code 1
>  make: Fatal error: Command failed for target `all'
>  Current working directory xxx/Modula-3/dist-1.6/libs
>  .ROOT/util/imake: Exit code 1.  Stop.
>  *** Error code 1
>  make: Fatal error: Command failed for target `system'
>  $

--
Bernd Deyhle
deyhle@peanuts.fmi.uni-passau.de


======================================================================== 13 ===
Date:    10 Nov 91 15:20:03 GMT
From:    dme@cl.cam.ac.uk (David Evers)
Subject: Re: Need help on installation of SRC Modula3

In article <1991Nov8.165119.25119@forwiss.uni-passau.de> deyhle@peanuts.name.fm
i.uni-passau.de writes:
>
>I trie to install SRC Modula-3 1.6 on a SPARC-SUN or a SUN3.
>Following the installation procedure I copy util/config.dist-SPARC
>to util/config. I set PREFIX to my home-directory and then call
>make system. But I allways get an error. So could someone please
>mail me what s going wrong:
>
>>  $ make system
>>  ---
>>  --- <<< stuff without errors deleted >>>
>>  ---
>>  --- ultrix-3-1 starting on Fri Nov 8 16:48:50 MET 1991
>>  ------ os starting on Fri Nov 8 16:48:52 MET 1991
>>  .ROOT/system/driver/m3.local -D../Interfaces -g -c Unix.i3
>>  M3 runtime error: Segmentation violation - possible attempt to
>   dereference NIL


I've seen what looks like this problem when building dist-1.6 for
SPARCs.  In my case what had happened was that the `configuration'
stage of the build, when architecture-specific diffs are applied to
the .mc and .ic files before the bootstrap compile (C->.o), had not
been completed.  Thus things like the thread support code were
using MIPS Ultrix jmpbuf definitions instead of SPARC ones, and when
the newly built m3compiler was first run, it segv'd in the Thread
module initialisation procedure.

It turned out that the reason the `config' phase had not completed
was that we had a broken version of /usr/bin/xargs which didn't
understand the `-l' option used by the top-level makefile's
`config' target.  So I just borrowed the sources for a working
version from another system, built a working xargs in .ROOT/util,
pointed the makefile at that, and it all worked.

So: I think that your `config' has failed, and it might be because
of a broken xargs.  If your logs contain a line like `-l: no such file',
then it would seem very likely.
								---- Dave

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


======================================================================== 14 ===
Date:    Mon, 11 Nov 91 14:36:03 PST
From:    Pat.Lashley@Eng.Sun.COM (Pat Lashley [MtV NeWStech Eng.])
Subject: :? link-compiler missing?

[ Third try - my newsreader crashed twice while trying to post this to
[ comp.lang.modula3, so I'm trying mail.  Appologies if any of you
[ recieve multiple copies.

I finally have time and disk space to try to build Modula-3 on my Sun
4/110 (SunOS 4.1.1), but the top-level makefile complains that it
doesn't know how to make `link-compile'.  A grep through the source
tree shows only one other occurrance of the string `link-' and that
is in an expression in libs/io/pickles/FastPkl.m3.

I recently ftp'd pub/DEC/Modula-3/m3-1.6/dist-1.6.tar.Z from
gatekeeper.dec.com, so the release should be up-to-date.


Any ideas?


-Pat


======================================================================== 15 ===
Date:    12 Nov 91 10:29:52 GMT
From:    laverman@cs.rug.nl (Bert Laverman)
Subject: Modula-3 opaque types and how to compile them

Hello all,

  Sorry to keep silent so long after causing a (new) thread of discussion.
I'm back now, and ready to run.

> [From the summary]
> The kinds of information that a compiler would like at compile
> time, but aren't available until later include:
>
> 1) offsets of fields & methods
> 2) the total size of the object
> 3) the default values of the fields & methods
> 4) which fields must be traced by the garbage collector
> 5) the full inheritance hierarchy

It seems to me that 1 and 2 (and sometimes possebly 3) could be solved with a l
inker
that knows how to resolve expressions containing external values. However, I ca
n imagine
that e.g. packed types will force even that small task to become possebly compl
ex.
  The offsets of fields and methods are not completely unknown, unless they are
. ;-)
Let me explain what I try to say: A module that doesn't know the fields in ques
tion,
because it has neither the declaration, nor a revelation, really doesn't need t
heir
offsets, since he can't use them anyway. A modula that _does_, knows the fields
of one entire inheritance level - I hope. Can you reveal only some fields? some
thing
like: `This object has these fields, but not necessarily in that order'? - whic
h is
at least something to start with. When considering multiple inheritance (ouch, 
ow! stop
it! just imagine that you do, you don't have to in reality... ;-)) the idea of 
a
descriptor containing pointers to the start of the different hiearchy levels an
d
branches comes as natural. Something like that could help here also, were it no
t that
we have (or rather: don't have) point 5.
  However, if we think of the descriptor as a record with fields at (yet) unkno
wn
offsets, it reduces to something comparable to 1.

  If the storing of values in fields at unknown positions is solved, 3 is not r
eally
a problem anymore, unless you want to optimize the allocation of new objects.
Hmmm, I suppose for every object type some kind of data structure needs to be b
uilt
to assist with the (a) allocation of a new object, (b) tracing of traceble fiel
ds
at destruction time.
  How is this done in SRC-m3?

Greetings, Bert


-- 
#include <std/disclaimer>

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


======================================================================== 16 ===
Date:    14 Nov 91 18:45:29 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: Pine Creek M3 Library - FieldList

Do you wish someone would publish interesting and useful Modula-3
libraries and software? Me, too. So, I am pleased to announce the
establishment of the Pine Creek Modula-3 Library and its first module,
FieldList. From time to time I will be adding software to this
library.

The software is available on gatekeeper.dec.com in directory
pub/DEC/Modula-3/pinecreek/library. (FYI, the newsletter on-line copy
has been mored to directory pinecreek/newsletter.)

Here is the release announcement for the first module in the library.
I welcome any feedback.

              THE PINE CREEK MODULA-3 LIBRARY

                      FieldList, v. 1.0
		(archived as file fl-1.0.tar.Z)

                      November 13, 1991

    Breaks text strings into fields, which can be processed as
    strings, characters, or numbers (integer and floating-point).
    Provides a quick and efficient way to parse input lines and allow
    free-form input of text and numbers.

The FieldList interface allows you to declare objects called field
lists. You can place a text string into a field list, or read a line
into it from a reader, and the text will be divided into whitespace-
separated fields.  The fields can then be processed in any order, as
text or numbers. You can use the same field list many times; each new
input line replaces the previous one.

INSTALLATION

The distribution consists of a single compressed tar file, fl-1.0.tar.Z.
To unpack the distribution, type

> uncompress -c fl-1.0.tar.Z | tar xvf - 

This will create a directory named fl-1.0 containing the two library
source files (FieldList.i3 and FieldList.m3), two sample programs
(Sum.m3 and Test.m3), this README file, a Makefile, and a 7-page
document in PostScript format (FieldList.ps).

Printed copies of the documentation are available if you cannot print
the PostScript file. Send a note to modula3@bert.pinecreek.com.

As an example of how FieldList might be used, here is a simple program that
reads in two numbers and prints their sum:

    MODULE Sum EXPORTS Main;
    IMPORT FieldList, Wr, Stdio, Fmt;

    PROCEDURE Put(t: TEXT) =
        BEGIN Wr.PutText(Stdio.stdout, t); END Put;

    VAR fl := NEW(FieldList.T).init();
    BEGIN
        LOOP
            Put("Type two numbers: ");
            fl.getLine();
            IF fl.number() # 2 THEN
                Put("Exactly two, please!\n");
            ELSE
                Put(Fmt.F("The sum of %s and %s is %s\n",
                    fl.text(0), fl.text(1), 
                    Fmt.LongReal(fl.real(0) + fl.real(1))));
            END;
        END;
    END Sum.

Here is some sample output from the program:

Type two numbers: 3, 56.8
The sum of 3 and 56.8 is 59.8

Enjoy!


======================================================================== 17 ===
Date:    Fri, 15 Nov 91 01:09:18 GMT
From:    mkh2704@ultb.rit.edu (M.K. Harry)
Subject: Compiling Modula3 on SUN 3


	While trying to compile the latest version of modula3
    retrieved from gatekeeper.dec.com for a SUN 3, I've encountered
    this error.  If anyone has any idea on how to remedy this problem
    or even how to attempt debugging it, I would greatly appreciate
    any suggestions.
						Mike


--- ultrix-3-1 starting on Thu Nov 14 19:21:59 EST 1991
------ os starting on Thu Nov 14 19:22:07 EST 1991
.ROOT/system/driver/m3.local -D../Interfaces -O -c Unix.i3
M3 runtime error: Segmentation violation - possible attempt to dereference NIL

Program .ROOT/system/compiler/m3compiler got fatal signal 3.
*** Error code 1
make: Fatal error: Command failed for target `Unix.io'
Current working directory /usr/local/src/modula3/dist-1.6/libs/ultrix-3-1/os
.ROOT/util/imake: Exit code 1.  Stop.
*** Error code 1
make: Fatal error: Command failed for target `all'
Current working directory /usr/local/src/modula3/dist-1.6/libs/ultrix-3-1
.ROOT/util/imake: Exit code 1.  Stop.
*** Error code 1
make: Fatal error: Command failed for target `all'
Current working directory /usr/local/src/modula3/dist-1.6/libs
.ROOT/util/imake: Exit code 1.  Stop.
*** Error code 1
make: Fatal error: Command failed for target `system'


----------------------------------------------------------------------------
mkh2704@ultb.isc.rit.edu  OR  mikeh@nick.csh.rit.edu

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


======================================================================== 18 ===
Date:    Thu, 14 Nov 1991 22:42:05 GMT
From:    mgallo@zeus.calpoly.edu (M. Gallo)
Subject: Oberon-2 documentation

Many thanks to Pfister@cs.inf.ethz.ch (Cuno Pfister), who just sent me
this information.  I think others on this news group may be interested.

>The new issue of "Structured Programming" should be out now, although
>I still haven't seen it.  There are mainly two papers in it about Oberon-2:
>"The Programming Language Oberon-2" by Hanspeter Moessenboeck and Niklaus
>Wirth, and "Differences between Oberon and Oberon-2", by the same authors.
>The latter is on pages 175-177, the former on pages 179-195.
-- 
IMHO, as always                                            _   /|
Miguel                                                     \'o.O'
mgallo@ares.calpoly.edu                                    =(___)=
"C is its own virus."                                         U


======================================================================== 19 ===
Date:    18 Nov 91 14:44:30 GMT
From:    S.A.Taylor@newcastle.ac.uk (Steve Taylor)
Subject: Micro/Macro Benchmarking of OOPLs

I am attempting to benchmark several OOPLs, including C++,
Modula-3, Eiffel, Sather and Simula, in order to assess the impact of
different language features and implementation techniques on performance.

I will be running a fairly full set of micro-benchmarks to test the
performance of individual language constructs, but I also hope to run
several macro-benchmarks to test the behaviour of `real' programs.

I have obtained the Dhrystone benchmark, but would also like to
get hold of some more object-oriented macro-benchmarks. If anyone
knows of the existence of such benchmarks or would like to suggest
a suitable benchmark, please mail me and I'll summarise to the net.
(I am aware of the recent controversy surrounding the Eiffel/C++
benchmark comparison)

                                S.A.Taylor@newcastle.ac.uk

                                     ( Steve Taylor )


======================================================================== 20 ===
Date:    18 Nov 91 20:25:49 GMT
From:    chambers@klamath.cs.washington.edu (Craig Chambers)
Subject: Re: Micro/Macro Benchmarking of OOPLs

As part of the Self language implementation project, we have collected
about 20 (relatively small) benchmark programs.  We have written
versions of these benchmarks in Self, C/C++, Smalltalk-80, T, and
(Allegro) Common Lisp.  The source code for these benchmarks is freely
available via anonymous ftp from self.stanford.edu, in the benchmarks
subdirectory.

If you port these benchmarks to other languages (M3 and Sather sound
like excellent choices, especially since both are freely available on
a wide variety of platforms; Eiffel would also be interesting to
measure), please let me or someone else in the Self group know so that
we can add your versions to our collection.  We'd also be interested
in adding any new benchmarks you create to our collection.  Finally,
if you get any interesting performance results, please let me know.

I'd also suggest that you get a copy of Self and benchmark it in
addition to your other more traditional platforms, if you have access
to a Sun-4.  You might also want to look at Smalltalk-80.

-- Craig Chambers


======================================================================== 21 ===
Date:    18 Nov 91 01:58:38 GMT
From:    nr@atomic.Princeton.EDU (Norman Ramsey)
Subject: Re: Modula-3 opaque types and how to compile them


In <1991Nov12.102952.1022@cs.rug.nl>, Bert Laverman (who would be well
advised to format his messages better) writes:

> It seems to me that [offsets of fields and methods] could be
> solved with a linker that knows how to resolve expressions containing
> external values. 

This is an odd kind of relocation, where the linker has to adjust the
size of displacement fields in some instruction.  The compiler has to
be sure to select an instruction with a displacement field large
enough to hold the adjusted value.  Perhaps this is a non-problem on
modern RISC architectures, which have whopping displacement fields,
but perhaps not.  In any case, it looks tricky.

If you're willing to defer instruction selection until link time, this
problem goes away.  I don't know what impact that might have on linker
performance...


======================================================================== 22 ===
Date:    18 Nov 91 10:53:28 GMT
From:    laverman@cs.rug.nl (Bert Laverman)
Subject: Generics, why are they in Modula-3?


Hi all,
  Well, this weekend the SPwM3 book arrived. Indeed there are some changes
as compared to the language report I found at gatekeeper, but apart from
the Generics I haven't been able to find anything remarkable.

  Those generics... I am a bit disappointed there. My initial impression
of Modula-3 was that - by introducing interfaces - import-by-name had at
last been conquered: what a module needs from the outside world could be
specified in an interface, and how that interface would be met would be
an external matter. i.e.: I was expecting to find references to a kind
of module interconnection method, that would specify things like: 'This
module's imported interface Y will be fulfilled by actual module X', and
so on.
  Appearently this is not the case. Sure, there is a sense of freedom in
module composition, but the kind of freedom I expected as being a basic
feature... shows up as something special called 'generics'.

  Components in a library. They export things, they import things. When
you build a program, you write the missing parts, and compose your program
from library components and newly written ones. Components that use the
aspect of an imported interface, are written to be combined with any
other component that exports an interface covering the imported interface.
In fact; different combinations of components make up new components.
  This seems to me a natural way of building programs, and I thougth this
is the Modula-3 method. Appearently this combinational aspect, choosing
from available components, and combining them to create a new component,
is what is _introduced_ by generics. This has me confused. Appearently
generics are nothing more than a way of getting the module interconnection
layout into the language itself.

  I'm not sure I agree with that.

  As I argue above, I think the importing and exporting of interfaces im-
mediately leads to this compositional approach of building programs. So why
introduce generics at all?
  ? To show that, when importing a certain interface, you are actually importin
g
    a whole hierarchy of modules?
  - Nah! Can't be, 'cause that is obvious anyway.
  ? To give some kind of requirements list for the parameter interfaces?
  - Nope, because there's no word even breathed about specifying requirements
    to imported interfaces.
  ? To be able to use the information imported from those parameters?
  - Not even that.
  Actually, the book states that an instantiation of a generic interface is
equivalent to an interface specification with renamed imports.

I can only conclude that Generics in Modula-3 seem to have been introduced to
specify just that which I thought the language featured anyway: The ability to
write a new component independent of what actual components are going to be
used to satisfy its import interface(s).

  So, the big question becomes:
	- What can I do with a parameter interface to a generic, that I cannot
	  do with a interface imported in the normal way?

Lets run down some possibilities:
  An interface exports any of the following:
	1) constants
	2) types
	3) variables
	4) procedures
  1) Constants have a type and a value. To use them, you must be able to use
	their type. If the type is fixed beforehand, the difference between
	a generic and a normal interface seems to be ... zilch.
	(sidestepping the missed oppportunaties for optimization)
	If their type is imported from the same interface, skip to pt 2.
  2) Whew. This seems to be the biggy. If you don't know in advance what a
	certain type is, you can't do much with it. Actually, what _can_ you do
	at all with an item of an imported type? For an imported interface, the
	interface will give a hint, usually either specifying the complete type
,
	or else giving a subtype hint. This pretty much fixes the amount of
	available activities on items of that type, since the interface gives
	you all the info you'll ever get or should need.
	  A parameter interface can export types about which we really don't kn
ow
	anything in advance. So what can we do with them:
	  - make/pass/use a reference to that item - tricky since we have to ke
ep
		track of where that reference goes.
	  - do an assignment - all we need is the storage size
	  - pass it as a parameter - again storage size needed.
	This is pretty much an Ada private type. (sorry ;-))
	If we do anything else on it, we are making it impossible to compile th
e
	generic component, since the compiler can't decide if what's happening
	is valid. Subscription, assignment from or to an item of a known type,
	de-referencing, etceteraa, etceteraa, etceteraa... You can't say a bloo
dy
	thing about the validity of these actions. You can at most try to check
	the consistency.
	  If we do want to be able to say something about it, we'll have to
	introduce subtyping specifications for other types that objects and
	references. IMHO that is a _very_ interesting subject. See OBJ.
  3), 4)
	I think point (2) describes the issues best, and they also relate to pt
s (1),
	(3), and (4).

  So, my conclusion would be that Generics in Modula-3 introduce a way of 
specifying that you can't specify things, and I think some extensions in M3's
subtyping features might solve a lot. _Then_ generics don't add anything new
anymore, and we can scrap them and go back to business, which I think should be
aimed at getting a good Module-interconnection specification method, and
maybe (sorry, a hobbyhorse) a limited form of type parameterization.

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

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


======================================================================== 23 ===
Date:    20 Nov 91 08:58:44
From:    vixie@decwrl.dec.com (Paul A Vixie)
Subject: modula-N (was: generics)

some day there will be a modula-oriented language that does not build in
the modula-3-style magic of NEW and LOCK and so on.  it will be possible
to extend the basic language to provide what the syntactic sugar in M3
gives you now.

we're getting there.  Pascal had writeln() et al that could not be written
in the basic language because of the :'s and the variable-length argument
lists and so on.  M3 finally fixes most of that (though i still miss the
":", i am very happy about "&" and although you can only pass arbitrary-
type arguments by REFANY, it's better than M2 or pascal).

i think that M3 is a useful language and a neccessary step in the evolution
back to cedar :-).  i plan to write quite a lot of code in M3 once real
(i.e., native) compilers become available.  it's quite a decent language
and will teach us a lot about what Modula-4 (or whatever) needs to be like.
it's also a lot of fun to code in.  i spent a week with it recently and then
had to go back to C for a fairly large project.  very difficult transition.
writing large programs in C is like building computer chips by going to the
beach with a bucket and bringing some sand back with you.

all that said, i basically agree with what was said today about Generics.
but even in their present somewhat stilted form, they can help generate
more code that is reusable and bug-free, and as such i am glad that they
will some day be available.
--
Paul Vixie, DEC Network Systems Lab
Palo Alto, California, USA           "Be neither a conformist or a rebel,
<vixie@decwrl.dec.com> decwrl!vixie   for they are really the same thing.
<paul@vixie.sf.ca.us>  vixie!paul     Find your own path, and stay on it." (me)


======================================================================== 24 ===
Date:    Wed, 20 Nov 91 09:27:23 PST
From:    <stolfi@src.dec.com>
Subject: Re: modula-N (was: generics)


    i think that M3 is a useful language and a neccessary step in the evolution
    back to cedar :-).

...which was only a necessary step in the evolution back to Algol-68. 8-)

--jorge




======================================================================== 25 ===
Date:    Wed, 20 Nov 91 10:22:52 PST
From:    ehs@src.dec.com (Ed Satterthwaite)
Subject: Re: modula-N (was: generics)

     i think that M3 is a useful language and a necessary step in the evolution
     back to cedar :-).
 
     ...which was only a necessary step in the evolution back to Algol-68. 8-)

Much of Mesa and Cedar WAS inspired by Algol 68.  It was disguised in Pascal-li
ke syntax in an attempt to avoid the incredibly negative PR that seemed to deli
ght the Algol 68 designers.

Ed



======================================================================== 26 ===
Date:    20 Nov 91 20:53:06 GMT
From:    sysessx@gsusgi2.gsu.edu (Eliza Strickler)
Subject: Is there Modula3 for Mips R3000 (Irix)?

I was wondering if a version of modula3 is out
that can be built under the Irix operating
system on a Mips R3000 machine? What about
Oberon? Any comments would be helpful.
-- 
===============================================================================
=
    Elizabeth Strickler           estrickl@gsu.edu           o/   
    Georgia State University      (404) 651-4573            /|  stay alive 
    Wells Computer Center                                   / >  


======================================================================== 27 ===
Date:    21 Nov 91 10:39:50 GMT
From:    laverman@cs.rug.nl (Bert Laverman)
Subject: Re: modula-N (was: generics)


Paul A Vixie writes:
> some day there will be a modula-oriented language that does not build in
> the modula-3-style magic of NEW and LOCK and so on.  it will be possible
> to extend the basic language to provide what the syntactic sugar in M3
> gives you now.

How about:

	PROCEDURE NEW(TYPE t <: REFANY): t =
	VAR p: t;
	BEGIN
	  p := LocalAllocate(SizeOf(t));
	  TypeCodeInit(p);
	  RETURN p
	END NEW;

	PROCEDURE TypeCodeInit(p : (TYPE t <: REFANY));
		<*RUNTIME-PACKAGE*>

	TYPE LockAction = PROCEDURE (VAR object : (TYPE t <: MUTEX));

	PROCEDURE LOCK(VAR object : (TYPE t <: MUTEX); doit : LockAction);
	BEGIN
	  Thread.Acquire(object);
	  doit(object);
	  Thread.Release(object)
	END LOCK;

Just some ideas. It is my firm conviction that type parameterization is
not necessarily inconveniencing to compiler builders.

> [ ... ]
> i spent a week with it recently and then
> had to go back to C for a fairly large project.  very difficult transition.
> writing large programs in C is like building computer chips by going to the
> beach with a bucket and bringing some sand back with you.
Hear, hear!

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

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


======================================================================== 28 ===
Date:    Thu, 21 Nov 91 15:12:25 GMT
From:    vixie@pa.dec.com (Paul Vixie)
Subject: Re: modula-N (was: generics)

The thing about NEW that I can't code by hand is

	VAR
		x := NEW(T, f := 1, m := foo);

The thing about LOCK that I can't code by hand is

	LOCK x DO

You can only provide this sort of thing from within the compiler, since
neither one follows the syntax of things the programmer is allowed to
define: NEW takes variable-magic argument lists, and LOCK has no (parens).
-- 
Paul Vixie, DEC Network Systems Lab
Palo Alto, California, USA           "Be neither a conformist or a rebel,
<vixie@decwrl.dec.com> decwrl!vixie   for they are really the same thing.
<paul@vixie.sf.ca.us>  vixie!paul     Find your own path, and stay on it." (me)


======================================================================== 29 ===
Date:    Thu, 21 Nov 91 13:21:22 PST
From:    Pat.Lashley@Eng.Sun.COM (Pat Lashley [MtV NeWStech Eng.])
Subject: Re: modula-N (was: generics)

|>  The thing about NEW that I can't code by hand is
|>  
|>  	VAR
|>  		x := NEW(T, f := 1, m := foo);
|>  
|>  The thing about LOCK that I can't code by hand is
|>  
|>  	LOCK x DO
|>  
|>  You can only provide this sort of thing from within the compiler, since
|>  neither one follows the syntax of things the programmer is allowed to
|>  define: NEW takes variable-magic argument lists, and LOCK has no (parens).

What you want is a -real- macro language (not to be confused with cpp or
m4.)  I worked with several in the early-middle 70's (CMC was probably
the best.)  They didn't catch on because of the enormous amount of memory
they needed - about 500k.  I have often considered resurecting CMC now
that it would be considered a medium-to-small program....



-Pat


======================================================================== 30 ===
Date:    22 Nov 91 03:04:37 GMT
From:    objsys@netcom.COM (Object Systems)
Subject: Reference Manual

Could someone please repost the address to request the latest 
Modula-3 Reference Manual.  Is this manual on-line?

Thanks,
Bob Hathaway
objsys@netcom.com


======================================================================== 31 ===
Date:    Fri, 22 Nov 91 10:41:35 EST
From:    wyant@saber.com
Subject: modula-N (was: generics)

>What you want is a -real- macro language (not to be confused with cpp or
>m4.)  I worked with several in the early-middle 70's (CMC was probably
>the best.)  They didn't catch on because of the enormous amount of memory
>they needed - about 500k.  I have often considered resurecting CMC now
>that it would be considered a medium-to-small program....
>
>-Pat

No, no, no ! You don't want a real-macro processor ! It makes it impossible
to write intelligent program analysis tools or do any sort of reasonable
incremental compilation. Please don't "fix" the language by adding on
additional preprocessors (especially when it ain't particularly broke ;-))

--Geoff Wyant
wyant@centerline.com
Centerline Software, Inc.
(formerly Saber Software, Inc.)


======================================================================== 32 ===
Date:    Fri, 22 Nov 91 08:46:06 PST
From:    Pat.Lashley@Eng.Sun.COM (Pat Lashley [MtV NeWStech Eng.])
Subject: Re: modula-N (was: generics)

|>  No, no, no ! You don't want a real-macro processor ! It makes it impossible
|>  to write intelligent program analysis tools or do any sort of reasonable
|>  incremental compilation. Please don't "fix" the language by adding on
|>  additional preprocessors (especially when it ain't particularly broke ;-))

Perhaps I wasn't clear here.  I don't think that m3 is broken, nor do
I think that it needs any pre-processors.  But the original poster was
complaining about not being able to write/override certain types of
operations that are `baked-in' to the compiler.  A good macro processor
would solve his problems.

I disagree with the contention that such a processor would make it
impossible to perform intelligent program analysis.  In fact, it might
make it easier - you could simply use a slightly different set of
expansions to generate the appropriate statistics gathering code.

I also object to the assumption that the macro language must be a pre-
processor distinct from the language itself.  The best results are
availiable by integrating the macro capabilities into the language
itself - that way the macro language can make tests that wouldn't
otherwise be availiable (e.g. check parameter type to implement
generics.)  In fact, the base language can be much simpler with a
good macro processor to impose the higher-level capabilities.
Structured programming constructs are usually described in terms of
label/goto, and simple conditionals.  They could just as easily be
described using loop/exit and case/else, and doing so would yield a
base more amenable to safe clean optimization and proof-of-correctness.

I'll admit that one of the few things I haven't done is write or maintain
an incremental compilation environment; but I don't see how building in
a good macro processor should significantly complicate the task.



-Pat


======================================================================== 33 ===
Date:    Fri, 22 Nov 91 09:20:08 PST
From:    <kalsow@src.dec.com>
Subject: Re: Modula-3 opaque types and how to compile them

Norman is correct that the linker would need to relocate displacement
fields.  It's not quite as unusual as he suggests.  Many machines
have branch or jump instructions with odd sized fields that must be
relocated.

The hard problem is that the value to be used in the relocation
is not simply an external constant.  It may be the sum of an
unknown number of external constants.  For example, consider
the following declarations:

    A.i3:     TYPE A <: ROOT;
    A.m3:     REVEAL A = OBJECT a: INTEGER END;
    B.i3:     TYPE B <: ROOT;
    B.m3:     REVEAL B = A OBJECT b: INTEGER END;
    C.i3:     TYPE C = B OBJECT c, d: INTEGER END;

The offset to the 'd' field is "sizeof (B) + sizeof (INTEGER)".
But, the size of B isn't a simple value, it's "sizeof (A) + sizeof (INTEGER)".

This type of relocation isn't particularly complicated.  As you noted,
it requires that the linker be able to evaluate simple expressions.
Unix 'ld' can't do this, probably other linkers can.

>  Can you reveal only some fields? something
>  like: `This object has these fields, but not necessarily in that order'?

No.

>  Hmmm, I suppose for every object type some kind of data structure needs
>  to be built to assist with the (a) allocation of a new object, (b) tracing
>  of traceble fields at destruction time.
>  How is this done in SRC-m3?

First, the SRC Modula-3 compiler computes a globally unique name for each
type.  Remember, Modula-3 has structural type equivalence so multiple
modules may define the same type.  The runtime needs to ensure that
the separate declarations are merged to produce a single type.

For each object type, the compiler generates a descriptor (a typecell)
that contains the following:

    - size and alignment of the locally defined data fields
    - number of new methods (i.e. non-overrides)
    - a pointer to the object's supertype's typecell (using
        the global names from above)
    - a procedure to finalize the descriptor (setup)
    - a procedure to initialize a newly allocated object (init)
    - a procedure to find the "pointers" in the object (trace)

At the beginning of program execution (logical "link time"), the
runtime does the following:

   First, it uses the supertype pointers to link the typecells into
   a tree that corresponds to the inheritance hierarchy.

   Then during a preorder traversal of the tree, it assigns typecodes 
   to each typecell. This order guarantees that for each type T, there 
   are a pair of integers FirstChild(T) and LastChild(T) such that 
   (X <: T) iff (FirstChild(T) <= TYPECODE(X) <= LastChild(T)).  
   Hence, we get an O(1) algorithm for implementing the ISSUBTYPE 
   operation.

   Finally, during a top-down traversal of the tree, the runtime computes 
   the total size and offsets of the data and method fields for each 
   type, allocates space for its method vector, and calls its 'setup' 
   procedure.  The setup procedure initializes the type's method vector 
   by copying its supertype's method vector and then adding its own 
   new methods and overrides.

When a new object of type T is allocated, the 'init' procedures on the
inheritance chain from ROOT to T are called.  They initialize the
object's fields with its default values.

During garbage collection and pickling the 'trace' procedures are
called.  They locate the traced refs, untraced refs and procedures
within an object.  The trace procedures make a call-back for each
"pointer" they locate.

  - Bill



======================================================================== 34 ===
Date:    23 Nov 91 14:54:00 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: macros (was: Re: modula-N (was: generics))

I agree with Geoff Wyant that macro processing at the textual/lexical level,
as provided in C and C++, is unstructured and not a very good approach from
the standpoint of language design and reliability. Macros as offered in LISP,
which operate syntactically rather than lexically are much more attractive.
Going beyond that, one can consider adding reflective capabilities to a
language. If reflection is allowed at run-time then a complex run-time is
required and it is hard constrain program semantics. However, we can consider
allowing reflection only at compile-time, as a technique for implementing
language extensions and automatic generation of pieces of code that fit
standardized patterns. Tim Sheard (formerly of UMass, now of Oregon Graduate
Institute) has an article in the latest TOPLAS about structure walking and
reduction routines, and he and David Stemple designed the language TRPL (Type
Reflective Programming Language) which allows such routine to be constructed
via compile-time reflection. I am not proposing that reflection be added to
Modula-3, but just trying to make the point that we *can* have disciplined
extension mechanisms in languages.
--

		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


======================================================================== 35 ===
Date:    23 Nov 91 20:12:12 GMT
From:    wilson@cs.utexas.edu (Paul Wilson)
Subject: Re: macros (was: Re: modula-N (was: generics))

In article <MOSS.91Nov23095400@ibis.cs.umass.edu> moss@cs.umass.edu writes:
>I agree with Geoff Wyant that macro processing at the textual/lexical level,
>as provided in C and C++, is unstructured and not a very good approach from
>the standpoint of language design and reliability. Macros as offered in LISP,
>which operate syntactically rather than lexically are much more attractive.

Lisp macros are still pretty ugly--- you get nasty scoping problems
and variable capture weirdness. This is because Lisp macros are only
syntactic in a very weak sense---they have no real notion of scope.

The long-awaited Revised Revised Revised Revised Report on Scheme (R4RS) 
describes the new high-level macro facility for Scheme.  These macros are
lexically scoped, like inline procedures, but more general than inline 
procedures.  You can define real control structures with them conveniently.

The R4RS is available by anonymous ftp from altdorf.lcs.mit.edu (or is
it altdorf.ai.mit.edu? I forget.)

>Going beyond that, one can consider adding reflective capabilities to a
>language. If reflection is allowed at run-time then a complex run-time is
>required and it is hard constrain program semantics. However, we can consider
>allowing reflection only at compile-time, as a technique for implementing
>language extensions and automatic generation of pieces of code that fit
>standardized patterns. Tim Sheard (formerly of UMass, now of Oregon Graduate
>Institute) has an article in the latest TOPLAS about structure walking and
>reduction routines, and he and David Stemple designed the language TRPL (Type
>Reflective Programming Language) which allows such routine to be constructed
>via compile-time reflection. I am not proposing that reflection be added to
>Modula-3, but just trying to make the point that we *can* have disciplined
>extension mechanisms in languages.
>--
>		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


Interesting stuff.  One of these days I've gotta figure out the relationships
between reflection, macroexpansion, and normal abstraction mechanisms....
(While most Scheme entities are first-class, macros aren't, at least not
in the normal direct sense.  Like compile-time-only reflection, this
lets you have your abstraction and your efficiency too.)

   -- Paul

P.S. For people who don't know about Scheme, it's a lexically-scoped variant
of Lisp, that's very elegant and fairly small.  I believe that McCarthy
has said something to the effect that Scheme is what he would have come
up with (instead of Lisp) if he'd read the whole book on the lambda calculus,
instead of just the first half.
-- 
| Paul R. Wilson, runtime environmentalist       email: wilson@cs.utexas.edu  |
| U. of Texas Computer Sciences Dept.            voice: (512) 471-9555        |
| Taylor Hall 2.124, Austin, TX 78712-1188       fax:   (512) 471-8885        |
                   "What doesn't kill me makes me stranger"


======================================================================== 36 ===
Date:    11 Nov 91 19:40:48 GMT
From:    patl@bodacia.Eng.Sun.COM (Pat Lashley [MtV NeWStech Eng.])
Subject: :? link-compile missing in SUN4 ??

I finally have disk space and time to bring up M3 (1.6) on my Sun 4/110,
but I have run into a wierd problem.  During the `make system', when it
reaches the `(cd compiler; .ROOT/util/m3all link-compiler)' line in the
top level makefile, it complains that it doesn't know how to make `link-
compile'.  Greping through the tree reveals only one other occurrance of
`link-', and that one is in an expression in libs/io/pickles/FastPkl.m3.


What's going on here?  I ftp'd the singel-file version of the distribution
from gatekeeper.dec.com just a few days ago.


Puzzled,
-Pat



X-Face: #FowkUVVz[9{ux;7z%!?7>\5DCdVqaja5uk!4Z~)5*f@-"n&||t35?wVN+UloPr-Q;iR\;t
 snA%,sJ:+$a[eV(aKz4\=`MIH#{`/#HW>TT6Hx=Xp06oj>ta|]bFa'1BiI5Wj_y7n,l)tFuEd(oE`V
 3w'0..-`[}nX:VVJ&@Br$cCu|/iqA4VC}/APx:gge9-fj(@V*~W[L@KP@^AcXvel])1%zy[&c}t"\z
 :X,J8<1D%I;J>tY6EZ7lx,8R&JhgPyZ4Zz[3J`#N@zc&d<"V+&O*;gRd^)xC`34h8[!Vb+

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


======================================================================== 37 ===
Date:    11 Nov 91 21:34:33 GMT
From:    patl@bodacia.Eng.Sun.COM (Pat Lashley [MtV NeWStech Eng.])
Subject: :? link-compiler missing in SPARC

[ Second try - my newsreader died while posting the first one. ]
[ My appologies if they both actually make it to the net...    ]

I finally have time and disk space to attempt a Modula-3 build on
my Sun 4/110 (SunOS 4.1.1).  The problem is that when the top level
makefile reaches the `(cd compiler; .ROOT/util/m3all link-compiler)'
line in the `system' target, it complains that it doesn't know how
to make link-compile.  A quick grep through the distribution reveals
that the only other use of the string `link-' is in an expression in
libs/io/pickles/FastPkl.m3.

I recently ftp'd the single-file distribution from gatekeeper.dec.com,
so it should be up-to-date.

Any ideas?


-Pat



X-Face: #FowkUVVz[9{ux;7z%!?7>\5DCdVqaja5uk!4Z~)5*f@-"n&||t35?wVN+UloPr-Q;iR\;t
 snA%,sJ:+$a[eV(aKz4\=`MIH#{`/#HW>TT6Hx=Xp06oj>ta|]bFa'1BiI5Wj_y7n,l)tFuEd(oE`V
 3w'0..-`[}nX:VVJ&@Br$cCu|/iqA4VC}/APx:gge9-fj(@V*~W[L@KP@^AcXvel])1%zy[&c}t"\z
 :X,J8<1D%I;J>tY6EZ7lx,8R&JhgPyZ4Zz[3J`#N@zc&d<"V+&O*;gRd^)xC`34h8[!Vb+

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


======================================================================== 38 ===
Date:    25 Nov 91 08:43:39 GMT
From:    laverman@cs.rug.nl (Bert Laverman)
Subject: Re: modula-N (was: generics)


Paul Vixie) writes:
> The thing about NEW that I can't code by hand is
> 
> 	VAR
> 		x := NEW(T, f := 1, m := foo);
Yes, while writing my example I thought of that.
Didn't stop me though. ;-)

> The thing about LOCK that I can't code by hand is
> 
> 	LOCK x DO
Now _this_ one can be done. M3 knows about parameters with
default values, doesn't it? Just make a 'DoNothing' the default.
  By the by, I wasn't really suggesting the replacement, it's
just a way of formalizing the effect of statements. My impression
of LOCK was that it is syntactic sugar, in which case it should be
possible to give a neat replacement. Hence LOCK().

> You can only provide this sort of thing from within the compiler, since
> neither one follows the syntax of things the programmer is allowed to
> define: NEW takes variable-magic argument lists, and LOCK has no (parens).
And this remark resulted in a lot of talk about macro processors.

I don't really like Macro-processors. Their only use seems to be providing
syntactic sugar, which shouldn't really be needed in a well thought out
language. If the extensions offered are 'in style', and the general opinion
is that they are useful, then it would be more logical to put it in the
language. If they are not in style, they should be avoided.
  Look what a preprocessor did to C. It's preprocessor, originally just
for getting named constants and an include-file mechanism, has now been
put in the language standard. Worse: a C language feature has been
defined in terms of preprocessor commands! (enum vs define)  I think
it's obsolete, since what previously was a tool to extend your programming
possibilities, is now a necessary part of the language. Better to put in
in with the compiler.

  As for the 'need' for a macro facility in Modula-3; I don't see it.
M3 doesn't need include files, it has interfaces. It doesn't need macro's,
it has constants and <*INLINE*> (which is pretty gross in itself, but I
suppose useful). It doesn't need code selection, just do your job and
modularize (ok, so a little dead-code elimination is useful too).

  The problem with preprocessors is that they tend to become compilers.
If you think you need one, better ask yourself if you're using the right
language.

Greetings, Bert

P.S. I hope nobody thinks I'm in for m3 bashing. I thinks it's the
way to go. Seeing everyday programming going to rot thanks to over-
enthousiasm for C/C++, I was relieved by finding m3. My bickering over
parameterization is a result of personal interest, and the (desparate)
need for clearing my head on the subject. Please don't hesitate to
disagree. ;-)
-- 
#include <std/disclaimer>

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


======================================================================== 39 ===
Date:    25 Nov 91 16:46:34 GMT
From:    hudson@cs.umass.edu (Rick Hudson)
Subject: Typo in Generic example.

The grammar on pg 63, says 
Decl = TYPE {TypeDecl ";"}
                      ^^^
which seems correct.
On pg 47 lines 1 and 9 the ";" was dropped.
- Rick
--

                Richard L. Hudson, Research Associate
                University Computing Services
                Lederle Graduate Research Center
                University of Massachusetts
                Amherst, MA  01003
                (413) 545-1220; Hudson@cs.umass.edu


======================================================================== 40 ===
Date:    26 Nov 91 12:14:39 GMT
From:    wsbusup4@rwb.urc.tue.nl (Jan Stout)
Subject: Re: modula-N (was: generics)

vixie@decwrl.dec.com (Paul A Vixie) writes:

>some day there will be a modula-oriented language that does not build in
>the modula-3-style magic of NEW and LOCK and so on.  it will be possible
>to extend the basic language to provide what the syntactic sugar in M3
>gives you now.

Try Forth for truly orthogonal extension of the basic language...

Jan Stout, wsbusup4@urc.tue.nl


======================================================================== 41 ===
Date:    Wed, 27 Nov 91 16:36:11 PST
From:    muller@src.dec.com (Eric Muller)
Subject: Re: Is there Modula3 for Mips R3000 (Irix)?

In article <sysessx.690670386@gsusgi1.gsu.edu>, sysessx@gsusgi2.gsu.edu (Eliza 
Strickler) writes:
> I was wondering if a version of modula3 is out
> that can be built under the Irix operating
> system on a Mips R3000 machine?

You may try to use the DS3100 architecture.  It may work just out of the box.

eric.



======================================================================== 42 ===
Date:    Wed, 27 Nov 91 16:42:46 PST
From:    muller@src.dec.com (Eric Muller)
Subject: Re: :? link-compiler missing in SPARC

In article <23108@exodus.Eng.Sun.COM>, patl@bodacia.Eng.Sun.COM (Pat Lashley [M
tV NeWStech Eng.]) writes:
> [ Second try - my newsreader died while posting the first one. ]
> [ My appologies if they both actually make it to the net...    ]
> 
> I finally have time and disk space to attempt a Modula-3 build on
> my Sun 4/110 (SunOS 4.1.1).  The problem is that when the top level
> makefile reaches the `(cd compiler; .ROOT/util/m3all link-compiler)'
> line in the `system' target, it complains that it doesn't know how
> to make link-compile.  A quick grep through the distribution reveals
> that the only other use of the string `link-' is in an expression in
> libs/io/pickles/FastPkl.m3.

There a 'link-compiler' target in the file system/compiler/Imakefile.
You should verify that this file did not disappear from your system.

Eric.



======================================================================== 43 ===
Date:    27 Nov 91 23:33:08 GMT
From:    lance@motcsd.csd.mot.com (lance.norskog)
Subject: DEC M3 -> NeXT report

Last April I did a hack port of DEC Modula-3 version 1.6 to
the NeXT workstation running OS 1.0.

From my notes:

	I copied the SUN-3 config file to make the NEXT config.

	system/corelib/Imakefile does 'library ()' when the library
	macro needs an argument.  I changed it to 'library (junk)'.
	The IBM R2 port uses the argument, the others don't.

	system/corelib/runtime/RTHeap.mc has funny RAM allocation:
	the first time through, it has an out-of-bounds RAM address but
	all subsequent addresses are OK.  (printf time).  So, I hacked
	it so that if an address is bad it allocates another one.

	Ranlib by default doesn't notice 'constants': what turns up
	as ' C symbol' in nm listings.  Changed ranlib to ranlib -c -s.

	Above ranlib change inspires annoying messages from /bin/ld.
	Changed CC rule to /usr/local/bin/m3cc and made a shell script
	there that does '/bin/cc -w' to get rid of messages.

As the Next and the SUN-3 come from the same BSD 4.2/4.3 lineage,
and both run on 68000's, it turns out that they are somewhat
binary-compatible.  SUN-3 apps which only do standard file I/O,
like 'cat', run perfectly on the NeXT.  So, obviously, you
want to put a SUN-3 and the NeXT side by side, build out the SUN-3
port, build out a NeXT port, and test out the pieces one by one.

I didn't have a SUN-3.  Most everything worked anyway.  There were
a few oddities in the compiler tools: /lib/cpp doesn't like some
files and ld and ranlib have trouble with constants.  Sprintf on
AT&T is a void, and the Next has AT&T and BSD modes kind of.
You always know what sprintf is going to return anyway, so the
code that relies on its return value should just 

Some of the X programs actually worked, too.  I was about to recycle
my tape from the project, so I figured I'd post my experiences.
I'm not interested in Modula-3 any more so I can't be of any assistance.

Good luck with M-3,

Lance Norskog

And get rid of those stupid capitalized keywords.


======================================================================== 44 ===
Date:    Wed, 27 Nov 91 17:46:24 PST
From:    Pat.Lashley@Eng.Sun.COM (Pat Lashley [MtV NeWStech Eng.])
Subject: Re: :? link-compiler missing in SPARC

|>  There a 'link-compiler' target in the file system/compiler/Imakefile.
|>  You should verify that this file did not disappear from your system.

There seems to be some sort of mail delay, I found the solution several
days before my message actually appeared on the list.

I finally re-ftp`d the distribution, and modified a copy of gnugrep
to not follow symlinks on a recursive diff.  When I compared the two
trees I discovered that the only difference was that one of the Imakefiles
in the original copy had been truncated.  I now have m3 up and running.



Thanks all,
-Pat


