======================================================================= 1 ===
Date:    1 Oct 1993 19:04:07 GMT
From:    Eric Muller <muller@src.dec.com>
Subject: Modula-3 Frequently Asked Questions (FAQ)

Archive-name: Modula-3-faq
Last-modified: Sep 9 1993


		 Modula-3 Frequently Asked Questions
		 ===================================


1. The language
	1.1 What is Modula-3?
	1.2 Is Modula-3 a superset of Modula-2?
2. The documentation
	2.1 Where can I get a description of Modula-3? 
	2.2 Where can I get other information on Modula-3?
3. The implementations
	3.1 Where can I get an implementation?
	3.2 What is SRC Modula-3?
	3.3 What is m3pc?
	3.4 What is GNU Modula-3?
4. Some specific questions
        4.1 Why is "Hello World" so large?
        4.2 Why objects and interfaces?
	4.3 What is the story with Trestle and OpenWindows?
        4.4 When is the next release of SRC Modula-3 ?
5. FTP
	5.1 What if I don't have ftp access?
6. Contributing
	6.1 Can I contribute Modula-3 software?




1.1. What is Modula-3?

   Modula-3 is a systems programming language that descends from Mesa,
   Modula-2, Cedar, and Modula-2+.  It also resembles its cousins
   Object Pascal, Oberon, and Euclid.

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


1.2. Is Modula-3 a superset of Modula-2?

   No; valid Modula-2 programs are not valid Modula-3 programs.  However,
   there is a tool to help convert Modula-2 programs to Modula-3.


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

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

   also known as SPwM3.  Here is the table of contents:

        1. Introduction
        2. Language Definition
        3. Standard Interfaces
        4. An Introduction to Programming with Threads
        5. Thread Synchronization: A Formal Specification
        6. I/O Streams: Abstract Types, Real Programs
        7. Trestle Window System Tutorial
        8. How the Language Got its Spots

   Chapters 2 and 3 have been reprinted in Sigplan Notices, Volume 27,
   Number 8, August 1992, pp 15-42.

   Sam Harbison has written a more tutorial book about Modula3:

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

   The errata sheet is available via anonymous ftp from gatekeeper.dec.com 
   in pub/DEC/Modula-3/errata.


2.2. Where can I get other information on Modula-3?

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

   There are a couple high-level overview articles available:

        "Modula-3", Sam Harbison, Byte, Vol. 15, No. 12, November 1990,
        pp 385+.

        "Safe Programming with Modula-3", Sam Harbison, Dr. Dobb's Journal,
        Vol. 17, No. 10, October 1992, pp 88+.

   A description of the Modula-3 type system is in

        "The Modula-3 Type System", Luca Cardelli, Jim Donahue, Mick Jordan,
        Bill Kalsow, Greg Nelson, Conference Record of the Sixteenth Annual
        ACM Symposium on Principles of Programming Languages (POPL), Austin
        Texas, January 11-13 1989, pp 202-212.

   The Trestle window system toolkit, higher-level FormsVBT toolkit, and
   Zeus animation system available with Modula-3, are documented in the
   following reports:

        "Trestle Reference Manual", Mark S. Manasse and Greg Nelson,
        SRC Research Report 68, December 1991.

        "Trestle Tutorial", Mark S. Manasse and Greg Nelson, SRC Research
        Report 69, May 1, 1992.

        "VBTkit Reference Manual: A toolkit for Trestle", edited by
        Marc H. Brown and James R. Meehan.  (soon to be a SRC Research
        Report)  A draft version is available via anonymous FTP from
        gatekeeper.dec.com in pub/DEC/Modula-3/contrib/vbtkit.25Mar93.ps.Z.

        "The FormsVBT Reference Manual", Marc H. Brown and James R. Meehan,
        (soon to be a SRC Research Report).  A draft version is available
        via anonymous FTP from gatekeeper.dec.com in
        pub/DEC/Modula-3/contrib/formsvbt.25Mar93.ps.Z and
        pub/DEC/Modula-3/contrib/formsvbt.AppC.26Mar93.ps.Z.

        "Zeus: A System for Algorithm Animation and Multi-View Editing",
        Marc H. Brown, SRC Research Report 75, February 28, 1992.
        Available via anonymous FTP from gatekeeper.dec.com in
        pub/DEC/SRC/research-reports/SRC-075*.ps.Z.

        "Color and Sound in Algorithm Animation", Marc H. Brown and
        John Hershberger, SRC Research Report 76a, August 30, 1991.
        Available via anonymous FTP from gatekeeper.dec.com in
        pub/DEC/SRC/research-reports/SRC-076a*.ps.Z.

        "The 1992 SRC Algorithm Animation Festival", Marc H. Brown, 
	SRC Research Report 98, March 27, 1993.  Available via anonymous ftp
        from gatekeeper.dec.com in 
        pub/DEC/SRC/research-reports/SRC-098*.ps.Z.

   Hardcopy versions of these reports can be ordered by e-mail; send your
   request including a postal mail address to src-reports@src.dec.com.


3.1. Where can I get an implementation?

   Two implementations are available, SRC Modula-3 and a
   PC version of it (m3pc).  Work is also progressing on GNU Modula-3.

   As far as we know, implementations are not available for VMS, Macintosh,
   or Alpha AXP/OSF.


3.2. What is SRC Modula-3?

   SRC Modula-3 was built by the DEC Systems Reseach Center
   and is available via anonymous ftp from gatekeeper.dec.com in
   pub/DEC/Modula-3/release.

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

        AIX386  IBM PC running AIX/PS2,
        AP3000  Apollo DN4500 running Domain/OS
        ARM     Acorn R260 running RISC iX 1.21
        DS3100  DECstation 3100 and 5000 running Ultrix 4.0 and 4.2
        HP300   HP 9000/300 running HP-UX 8.0
	HPPA    HP 700/800 running HP-UX 8.0
        IBMR2   IBM R6000 running AIX 3.1, 
        IBMRT   IBM RT running IBM/4.3, 
        NEXT    NeXT running ??
	OKI     Okidata 7300 (i860) running AT&T SVR4.0
        SPARC   SPARCstation running SunOS 4.1.x
        SUN3    SUN3 running SunOS
	SUN386  Sun 386i  running SunOS 4.0.1
        UMAX    Encore Multimax running UMAX 4.3 (R4.1.1)
        VAX     VAX running Ultrix 3.1

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

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


3.3. What is m3pc?

   m3pc is available via anonymous ftp from gatekeeper.dec.com in
   pub/DEC/Modula-3/contrib/m3pc.

   From: laszlo@post.ifi.uni-klu.ac.at (Prof.Dr.Laszlo BOESZOERMENYI)
   Subject: M3 pn PC
   Date: 8 Mar 1993 13:13:52 GMT

   The Modula-3 system ported by us on the PC and available on the
   gatekeeper, runs with MSDOS, gnu c compiler and djgpp memory
   manager (detailed description in the read me file).

   You may compile, link and run Modula-3 programs, without threads.
   From the library modules only those are tested which are used by
   the compiler.  In the course of a student project a
   "student-friendly" environment is in development.  It will be
   available at end of June (hopefully).


3.4. What is GNU Modula-3?

   From: moss@cs.cmu.edu (Eliot Moss)
   Subject: GNU Modula-3 alpha release status
   Date: 25 Mar 93 17:53:12 GMT

   We said we'd try to get the initial (alpha) release of GNU
   Modula-3 out some time this month (March), and we're in the
   process of figuring out what to release and how to package it
   up. We expect to have something in roughly two weeks (watch
   this space for a notice).

   What would this be? First, it is a compiler for the VAX (only)
   under Ultrix (only), definitely without threads, and probably
   still failing a small number of the tests in the SRC test
   suite (which implies that not all of libm3 is likely to work
   either). The actual release information will detail more about
   what's working and what's not at that time. We DO currently
   pass all the compiler tests that the SRC compiler did when it
   was first released (i.e., the ones we fail are more obscure
   things that users uncovered over time).

   Second, the release itself will be a compressed tar file
   including sources and executables. The executables will
   probably work only if you put libraries, etc., in the expected
   places (otherwise, you'll need to rebuild from sources).The
   compiler is written in C and should be compiled with a recent
   version of gcc (so you'll need gcc installed). The system also
   uses gld (the GNU linker).

   This release should be most useful to people undertaking ports
   to other machines and operating systems, since it will give
   them a head start on understanding the compiler and getting
   the full system ready. It may be of some use for ordinary
   programming, but it really depends on whether you tend to use
   features that tickle the remaining bugs. We are indeed
   interested in alpha test reports, but only if they tell us
   something new (i.e., we'll provide a list of known
   deficiencies).

   When the release is made, we'll also start email discussions
   with the various parties who have indicated they might
   undertake ports, to help sort out who will do what.

   Regards, and thanks for your continued interest and
   encouragement -- EM

   From: moss@cs.cmu.edu (Eliot Moss)
   Subject: GNU Modula-3 pre-release
   Date: Wed, 5 May 1993 23:49:33 GMT

   At long last, the GNU Modula-3 project has a pre-release ready, for
   the VAX/Ultrix platform ONLY. Various folks had notified us of
   their interest in doing ports or alpha testing, and they have
   already been sent email with particulars on how to obtain the tar
   file, etc. There are a number of known bugs; I'll see about making
   a list available by ftp or something, for interested parties.

   It is our opinion that the prerelease is not mature enough for
   general use, but we wished to give a head start to those folks
   attempting ports, and we will make periodic patches available. If
   you want to use this compiler for serious program development or
   need something solid with debugging support for classroom use, you
   should wait until we've fixed more of the problems. (But to give a
   sense of what we HAVE accomplished, as I recall, all but 3 of the
   SRC compiler tests compile (there are 137 of them).) We hope to do
   a more general release, and support more platforms, in the summer.

   If you're interested in helping and have not previously contacted
   us, please send email to me and/or Rick Hudson
   (hudson@cs.umass.edu).

   Thanks to Digital and SRC for supporting us, and to Rick Hudson, Amer Diwan,
   and Norm Walsh, the guys who do all the hard work!


4.1. Why is "Hello World" so large?

   Modula-3 programs are larger than C programs for the following reasons:

     1) The fixed runtime is substantially larger.  It contains a
        garbage collector, a thread runtime, and exception support.
        Note that "Hello World" is virtually all runtime.  For
        larger programs the runtime is not an issue.

     2) The generated code includes runtime checks for out-of-bound
        array references and NIL pointer.  Many of these checks could
        be removed by a better compiler.  The current compiler is
        only a research prototype.

     3) The compiler generates C code as its intermediate language
        consequently the final machine code suffers.  For example,
        the compiler is constantly storing single-precision floating
        point values into memory to get around C's predisposition
        for double precision.

4.2. Why objects and interfaces?

   Allan Heydon on comp.lang.modula3,  May 4th 1993:

   Modula-3 provides two separate mechanisms for data-hiding: one for 
   hiding details about how interfaces are implemented, and the other 
   for hiding details about how objects are implemented.

   The first data-hiding mechanism is realized by the distinction between 
   interfaces and modules. Clients can only import interfaces, so the 
   names declared in the modules implementing those interfaces are hidden 
   from clients. Note that this mechanism has only two levels; a name 
   is either declared in an interface, or it isn't. If a name is only 
   declared in a module, it can't be used by a client. 

   The second data-hiding mechanism is realized by opaque types and 
   revelations. A Modula-3 interface may declare an object type to be 
   opaque, in which case only a subset of the fields and methods of 
   that object are revealed to clients importing the interface. Furthermore, 
   the Modula-3 revelation mechanism allows a designer to reveal successively 
   more fields and methods of an object in a series of interfaces. The 
   fields and methods visible to a client then depends on which interfaces 
   the client imports. 

   The latter mechanism is quite flexible. As opposed to the interface/module 
   data-hiding mechanism, opaque types allow you to define an arbitrary 
   number of levels at which more and more information about the implementation
 
   of your object is revealed. 

   See Sections 2.2.10, 2.4.6, and 2.4.7 of "Systems Programming with 
   Modula-3" for more information about opaque types and about partial 
   and complete revelations. 

4.3. What is the story with Trestle and OpenWindows?

   Mark Manasse says: 

   I think that the OpenWindows release should be enough (no need to 
   get the MIT X release], although there are a few things in Trestle
   that trigger devastating bugs in OpenWindows. But the only library
   we depend on is Xlib, R4 or later.

   The main thing I know that crashes OW 2.0 is the code where we call 
   GrabKey specifying AnyKey.  You can either loop over all of the 
   keys, or you can just comment out the call; programs won't run exactly 
   the same, but you probably won't notice the difference.


4.4 When is the next release of SRC Modula-3 ?

  The next release will be 3.0.  Here are some of the new things you will
  find in it:
  
  1. the compiler has a new internal interface between the front-end and
     the back-end, M3CG.  This interface is supposed to be easy to
     implement.
  
  2. the front-end can compute in the target arithmetic system; in particular
     it is possible to cross-compile to machines with larger integers than
     the host.
  
  3. one back-end has been implemented on top of gcc.  The implementation of
     M3CG interface generates the tree representation used internally in gcc.
     From the gcc point of view, this back-end looks like a new front-end.
     Using this back-end, we have cross-compiled solitaire for mips, alpha and
     386 processors; there is no reason to believe that there would be a
     problem for the other architectures supported by gcc.
  
  4. Dave Hanson wrote another implementation of the M3CG that is
     self-contained. He is currently working on the 386 code generation (he
     has done the mips code generation already).
  
  5. gdb has been modified to understand Modula-3 debugging information
     produced by the back-ends.  gdb can now parse Modula-3 expressions, print
     Modula-3 values and evaluate some of the Modula-3 built-in operations.
     There is also a little bit of support for multi-threaded programs (you
     can look at the stacks of other threads).
  
  6. there is a replacement for m3make, m3build, that does not rely on
     cpp/awk/sed/make and what not, and removes some of the limitations of
     m3make.  m3makefiles are very similar.
  
  7. libm3 has been significantly changed by the Interface Police, mostly in
     the area of OS interfaces and data structures.
  
  8. for the OS interfaces, we still have the U* interfaces, but applications
     are not supposed to use those.  Instead they should use a new set of
     interfaces that are os-independent; for example, there is a Pathname
     interface that manipulates file names; there is a Process interface that
     manipulate child processes.  These interfaces enabled a prototype port
     of the C based version to Windows NT machines.
  
  9. for the data structures, generics have been introduced and the various
     data structures are more consistent.
  
  10. because of 6 and 8, we can think about going to different os than Unix.
      In particular a Windows NT port will be available at some point (may not
      be in 3.0).
  
  11. the runtime has been improved quite a bit.
  
  12. new platforms: Alpha running OSF/1, 386 running Linux.  We will pay
      more attention to the porting instructions and support.
  
  13. I am not sure about all the changes in the libraries other than
      libm3.  I suspect that there will be few changes in trestle, but that
      mentor changed quite a bit. 
  
  14. The Windows NT port uses native threads.  This should be a good model
      for other implementations of Thread using native threads.

  The current status is:
  . the front-end is very stable
  . the gcc-based back-end has been stable for 4 months
  . the gdb extensions are brand new and need some test
  . the interface police work is very stable
  . we are working on bringing the system up on the machines we have in the
    building, and building the export machinery.
  
  We don't have a date for the 3.0 release.  Given the amount of changes
  introduced by 3.0, I suspect that the first few releases will not work out
  of the box for any machine but the ones for which we can test (decstations
  [mips and alpha], linux).  Consequently, I expect a high rate of releases
  for a while.  We will try to post accurate information about the status of
  each machine, but we can only rely what you tell us.
  
  At this point, I would not encourage anybody to start a new port.  If you
  have a new port, or are close to complete one, you can send us your bits,
  we will try to put them in 3.0.
  
  
5.1. What if I don't have ftp access?
  
   Unfortunately, we cannot deliver Modula-3 other than by 
   anonymous ftp.  

   Fortunately, Prime Time Freeware (PTF) includes Modula-3.  PTF is
   a set of two ISO-9660 CDroms filled with 3GB of freeware, issued
   semi-annually.  The latest issue, Volume 1, Number 2, July 1992,
   contains SRC Modula-3 2.07.  PTF is distributed via bookstores and
   mail.  You can reach PTF using:

	Email:  ptf@cfcl.com
        Fax:    [1] (408) 738 2050
        Voice:  [1] (408) 738 4832
        Mail:   Prime Time Freeware
 	        415-112 N. Mary Ave., Suite 50
		Sunnyvale, CA 94086
	        USA

6.1. Can I contribute Modula-3 software?

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

   Right now, the pub/DEC/Modula-3/contrib directory contains:

      m3rpc   an rpc system from Xerox Parc
      M2toM3  a translator from Modula-2 to Modula-3
      m3pc    an implementation of Modula-3 for PCs.
   
----
Eric.


======================================================================= 2 ===
Date:    2 Oct 1993 22:21:19 GMT
From:    steveq@umiacs.umd.edu (Stephen Quirolgico)
Subject: Modula* compilers

Hi,

Does anyone know if there is a Modula* compiler for a SIMD (CM-1), SAMD (CM-5) 
or Cray T3D?

Also, does anyone have any information on the Triton project from the
University of Karlsruhe in Germany?

-Stephen Quirolgico




======================================================================= 3 ===
Date:    Sun, 3 Oct 1993 23:02:19 GMT
From:    jmkomine@napier.uwaterloo.ca (John Kominek)
Subject: Re: Is there an OS/2 2.x Port for Modula3?

In article <1993Sep28.222906.26419@sifon.cc.mcgill.ca>, whitney@oberon.Meakins.
McGill.CA () writes:
> Craig Kingston (ckingsto@descartes.uwaterloo.ca) wrote:
> : Does Anyone know of a port - or a plan to port Modula-3 
>  to OS/2 2.x.
> 
> It is not M3, but might be helpful as interim solution.
> Extacy by RTA makes a very good Modula-2 to C translator. 
> The same translator also supports Oberon-2 and the languages
> can be mixed. ( I use it as Oberon-2 on OS/2 ). 
> They may or may not have done some work on Modula-3.
> 
> Here is their address.
> 
> Real Time Associates Ltd,          Tel        : (+44)(0)81 656 7333/4/5
> Canning House, 59 Canning Road,    Fax        : (+44)(0)81 655 0401
> Croydon,Surrey,CR0 6QF             Email      : ian@rtal.demon.co.uk
> UK                                 Compuserve : 71333,2456      
> 
> 
> Whitney


Do they supply the C compiler or is that for you to do?

John Kominek


======================================================================= 4 ===
Date:    4 Oct 1993 15:08:17 GMT
From:    mead@bucknell.edu (Jerry Mead)
Subject: Modula-3 based CS1 texts???


I posted this question early in the summer and got no replies.
So here goes again.  Do any of you know of plans for a CS1 text
based on Modula-3.  Seems that the existence of such a text would
end at least some of the C++ vs Modula-2 in CS1/2 wars.

Thanks - if anything interesting comes up I will post a summary.

jerry

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

Jerry Mead
Dept of Computer Science
Bucknell University
Lewisburg, PA 17837
mead@bucknell.edu



======================================================================= 5 ===
Date:    7 Oct 1993 08:47:02 GMT
From:    laverman@cs.rug.nl (Bert Laverman)
Subject: Re: Why structural equivalence?

Michael Werts writes:
> Subject line says it all. Structural equivalence
> strikes me as UNOBJECT-ORIENTED. What is the
                ^^^^^^^^^^^^^^^^^
Interesting term. Please explain. Perhaps this would require
an explanation of what you see as Object-Oriented.

PS Objects a-la OBJ also use what can be termed as structural
   equivalence, be it that not only the data structure, but
   also the algebraic specification of operators/functions is
   included.

Greetings, Bert
-- 
  ------------------------------------------------------------------
  Bert Laverman,   Dept. of Computing Science,  Groningen University
  Email: laverman@cs.rug.nl			Phone: +31-50-633948
  Home:  bert@rakis.iaf.nl			Fax:   +31-50-633800


======================================================================= 6 ===
Date:    7 Oct 1993 04:02:43 GMT
From:    werts@beach.csulb.edu (Michael Werts)
Subject: Why structural equivalence?

Subject line says it all. Structural equivalence
strikes me as UNOBJECT-ORIENTED. What is the
rationale for structural equivalence in Modula-3?

Thanks.


-- 

MICHAEL WERTS -- werts@csulb.edu
Computer Engineering Computer Science
California State University Long Beach


======================================================================= 7 ===
Date:    7 Oct 1993 13:37:33 GMT
From:    pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
Subject: Re: Why structural equivalence?


werts@beach.csulb.edu (Michael Werts) writes:

>Subject line says it all. Structural equivalence
>strikes me as UNOBJECT-ORIENTED. What is the
>rationale for structural equivalence in Modula-3?
>

Citation from Harbison's Modula-3 book:
  Modula-3's structural equivalence is considered by some to be one of
  the language's weaknesses. These people prefer "name equivalence", in
  which types that are given different names are treated as distinct
  and cannot accidentally be mixed just because their structure happens
  to be the same.
  Under the name equivalence rules used by C, Pascal, and Modula-2, new
  types come into being when special type constructors are used, such
  as RECORD ... END, union {}, SET OF ..., etc. However, a simple
  "renaming" declaration does not create a new type. Consider these
  declarations:
    TYPE
      Apple = RECORD size: REAL END; (* Pascal, Modula-2 *)
      Orange = RECORD size: REAL END;
      Lemon = Orange;
  In Modula-3, Apple, Lemon, and Orange are all the same type. In Pascal,
  Modula-2, and C, Apple and Orange would be different types, but you
  could still mix Lemons and Oranges: they're the same type even though
  they have different names. Furthermore, you can never create "new"
  integers or floating-point types. So, name equivalence has its own
  loopholes.
  Ada takes name equivalence further; you can create "new" integer types
  by writing
    TYPE InventoryCode = NEW INTEGER;
  InventoryCode is not the same as INTEGER. However, since the new type
  is still an "integers" in some sense, there is a complicated set of
  rules that allows InventoryCode to inherit many of the INTEGER
  operations, so that you can assign integer literals to InventoryCode
  variables, etc.
  Structural equivalence is easy to explain and is adequately safe in
  most cases. It is superior to name equivalence when programming
  distributed systems, in which seperate programs must communicate
  typed data. There are some important situations in which you want to
  "disable" structural equivalence to prevent a hidden type from being
  "guessed"; this is handled in Modula-3 by "branded" types, which are
  discussed in Chapters 10 and 11.

My personal opinion:
  - Structural equivalence makes life easier in many standard situations.
  - It does not interfere with information hiding, since opaque types
    *have* to be branded and are therefore incompatible to all other
    types.

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




======================================================================= 8 ===
Date:    Thu, 07 Oct 93 12:56:57 GMT
From:    will@marvin.or.uni-bonn.de (Hans-Martin Will)
Subject: SRC Modula-3 for IBMR2 / RS6000


Does anybody know about an adaption of SRC-Modula-3 to the IBMR2
with all stub modules replaced by "real" working code?
Thanks in advance,

Martin Will
will@marvin.or.uni-bonn.DE


======================================================================= 9 ===
Date:    Thu, 7 Oct 93 13:45:43 EDT
From:    wewang@rodan.syr.edu (Wen-shyan Wang)
Subject: only test

 Sorry, this is for test.



======================================================================= 10 ===
Date:    9 Oct 1993 00:09:27 GMT
From:    mbk%anl433.uucp@Germany.EU.net (Matt Kennel)
Subject: Re: Why structural equivalence?

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


:   Structural equivalence is easy to explain and is adequately safe in
:   most cases. 

Is a complex number always the same as a two-dimensional vector?

No.  You can't divide vectors.

Structural equivalence also seems to focus too much on data "attributes",
and ignores the other half of the object---the methods.  Witness the
above example.

And finally, two things that happen to be structurally equivalent
in one implementation may not remain so with subtypes thereof.  (Not sure
here)

It also goes against the "spirit" of the concept of a named type. (You
gave it a name for a reason).

If you have a langauge that allows one to put new abstract types "over"
already existing concrete ones (e.g. Sather), then it seems superfluous,
and potentially confusing.


: Peter
: ---

--
-Matt Kennel  		mbk@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".


======================================================================= 11 ===
Date:    9 Oct 1993 01:17:56 GMT
From:    agulbra@nvg.unit.no (Arnt Gulbrandsen)
Subject: Re: Why structural equivalence?

In article <294vfnINNr96@network.ucsd.edu>,
Matt Kennel <mbk%anl433.uucp@Germany.EU.net> wrote:
>Structural equivalence also seems to focus too much on data "attributes",
>and ignores the other half of the object---the methods.

No.  Two otherwise equal types with a different set of methods
aren't structurally equivalent, merely storage-wise.  If both types
have a method INTEGER (FLOAT, FLOAT) which does completely different
things, they might be structurally equivalent.

>It also goes against the "spirit" of the concept of a named type. (You
>gave it a name for a reason).

If you have a reason to make a type special, you brand it.

-- 
Arnt Gulbrandsen, agulbra@nvg.unit.no
This is what's known as a double entendre.
--
Arnt Gulbrandsen, agulbra@nvg.unit.no
This is what's known as a double entendre.


======================================================================= 12 ===
Date:    11 Oct 1993 08:55:34 GMT
From:    laverman@cs.rug.nl (Bert Laverman)
Subject: Re: Why structural equivalence?

Matt Kennel writes:
> Is a complex number always the same as a two-dimensional vector?
Please! Structural equivalence does not necessarily mean 'ignoring field
labels'. Only when you have two record types with equal field names
can you start to consider equality, which is what Modula-3 does.

> Structural equivalence also seems to focus too much on data "attributes",
> and ignores the other half of the object---the methods.  Witness the
> above example.
Please elaborate. What kind of structural equivalence are you attacking
here? Methods form a part of an object's structure, at least with M-3.

> And finally, two things that happen to be structurally equivalent
> in one implementation may not remain so with subtypes thereof.
> (Not sure here)
Quite. I suppose you mean to say that if A and B are equal (according
to struct. eq.) and A' <: A, then the implied A' <: B may not be
wanted? If so, then the original A = B was already unwanted, in which
case you probably should have branded A and B to make them distinct.


> It also goes against the "spirit" of the concept of a named type. (You
> gave it a name for a reason).
When the choice between named and structural goes to structural, indeed
the principles of named will be violated.

> If you have a langauge that allows one to put new abstract types "over"
> already existing concrete ones (e.g. Sather), then it seems superfluous,
> and potentially confusing.
I don't know sather, but please keep your comments relevant to the
language under discussion. For M-3 structural equivalence works fine.
That it may not do so for other languages is irrelevant.

Bert

  ------------------------------------------------------------------
  Bert Laverman,   Dept. of Computing Science,  Groningen University
  Email: laverman@cs.rug.nl			Phone: +31-50-633948
  Home:  bert@rakis.iaf.nl			Fax:   +31-50-633800


======================================================================= 13 ===
Date:    11 Oct 1993 17:13:26 GMT
From:    dat93jpe@ludat.lth.se (Jan Persson)
Subject: Is there any M3 port to Linux?

Just as the headerline says.
Is there any port of M3 to Linux?
Or is there someone who is working on it?

Regards /Janne



======================================================================= 14 ===
Date:    Tue, 12 Oct 1993 15:23:32 GMT
From:    dagenais@gutrune.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: Is there any M3 port to Linux?


The upcoming DEC SRC Modula-3 3.0 release is in alpha test right now
and supports LINUX directly. The last i heard the Linux port was
a bit ahead of the Sparc port :-). It should not be very long.
I will announce the availability of binaries on comp.os.linux.announce.

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

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

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


======================================================================= 15 ===
Date:    12 Oct 1993 18:06:08 GMT
From:    madon@disuns2.epfl.ch (Dominik Madon)
Subject: M3 for NEXSTEP intel

Is there a SRC M3 version (2.x or 3.0) for NEXSTEP intel ?

Thanks for answers.

Dominik Madon

-----------------------------------------------------------------
madon@di.epfl.ch Ecole Polytechnique Federale de Lausanne CH
-----------------------------------------------------------------


======================================================================= 16 ===
Date:    Wed, 13 Oct 1993 07:05:15 GMT
From:    skj@oasis.icl.co.uk (Simon Johnston)
Subject: Re: Is there any M3 port to Linux?

Michel Dagenais (dagenais@gutrune.vlsi.polymtl.ca) wrote:
: The upcoming DEC SRC Modula-3 3.0 release is in alpha test right now
: and supports LINUX directly. The last i heard the Linux port was
: a bit ahead of the Sparc port :-). It should not be very long.
: I will announce the availability of binaries on comp.os.linux.announce.

Please can we have access to ALPHA/BETA code for evaluation / testing. I
really want to get my hands on the Linux code to see what sort of performance
the compiler / runtime gives.


MODULE Sig;
FROM ICL IMPORT StdDisclaimer;

BEGIN
(* ------------------------------------------------------------------------.
|Simon K. Johnston - Development Engineer              |ICL Retail Systems |
|------------------------------------------------------|3/4 Willoughby Road|
|Unix Mail : S.K.Johnston.bra0801@oasis.icl.co.uk      |Bracknell, Berks   |
|Telephone : +44 (0)344 476320   Fax: +44 (0)344 476084|United Kingdom     |
|Internal  : 7621 6320    OP Mail: S.K.Johnston@BRA0801|RG12 8TJ           |
`------------------------------------------------------------------------ *)
END Sig.


======================================================================= 17 ===
Date:    Wed, 13 Oct 1993 04:01:35 GMT
From:    Bob Hathaway <rjh@geodesic.com>
Subject: Comp.Object FAQ Version 1.0.3 (10-12) Announcement

This announces the October version 1.0.3 of the Comp.Object FAQ!  It has many
updates and corrections and has several very up-to-date appendices on object-
oriented methodologies and systems.  It may very well comprise the latest
and most up-to-date collection of object-oriented systems and terminology in
the world today!

New noteworthy additions are the OO methodologies and OOA/OOD sections and ever
expanding appendices.  Future FAQs will contain a diff file.  The FAQ is
updated and posted monthly.  Comments, suggestions, additions, updates, and new
systems and site entries should be sent to rjh@geodesic.com.  

The FAQ is posted to the comp.object, comp.answers and news.answers newsgroups
and is available via anonymous ftp from zaphod.uchicago.edu and rtfm.mit.edu,
although new versions may be temporarily found in zaphod's /uploads directory.
A hypertext version is also available, see the FAQ for details.

Thank you to the many people who have contributed their time and effort into
helping this document spread the word about object-oriented technology and
available systems!  It is hoped it will be most useful in that endeavor.

Best Regards!
bob


======================================================================= 18 ===
Date:    Wed, 13 Oct 1993 14:12:05 GMT
From:    george@bcstec.ca.boeing.com (Harry G. George)
Subject: M3 in a C/C++ world

Thank you to those who responded to my query re running
trestle on SUN.  The fixes worked. Thank you to those who designed 
and built trestle, vbt, et al. Looks like a clean, robust approach.

OTOH, we live in a C/C++/Motif world.  I might be able to
sell folks on Modula3 as a replacement for C++, or as a code generator
for C.  But I can't ignore the growing reuse libraries of Motif-based
widgets.  (Betamax may have been better than VHS, but VHS won.)  Therefore:

Does anyone have a set of Motif .i3 files (e.g., following the pattern
of the X and Xt interfaces in the M3 release)?  If not , is anyone 
interested in helping prepare a PD version of same?  

We really need a general C-to-Modula3 translator, which converts .h files
to .i3 files.  It needs to understand the preprocessor commands, e.g.
    #include "Abc.h"     --> IMPORT Abc;
    #define abc          --> CONST abc = TRUE;
    #define def 2.345    --> CONST def = 2.345;
    #define ghi "Hello"  --> [in .i3] VAR ghi := CharStar;
                             [in .m3] ghi := TtoS("Hello");
    #define jkl (x) (x*3)--> <*INLINE*>
                             PROCEDURE jkl(x:INTEGER):INTEGER =
                             BEGIN
                               RETURN x*3;
			     END jkl;

Of course, there is likely to be some hand-tweaking, but a good translator
would keep us in the game as more and more C libraries arrive in the
market.

I built a Perl script which does part of the job.  I've been thinking of 
trying to use TXL or PCCTS to do a more robust job.  Sure would like
to hear that someone else has already solved it.

[Reply to address below]
---------------------------------------------------------
Disclaimer:  Any opinions expressed herein are my own and
             not those of The Boeing Company.
Contact:     Harry George, BCAG Automated Software Analysis  
Phone:       (206) 237-6915  Org: 6-6541  M-S: 6A-UA
E-mail:      george@garden.ca.boeing.com
IP address:  137.137.45.51                     



======================================================================= 19 ===
Date:    Wed, 13 Oct 1993 14:24:06 GMT
From:    dagenais@gutrune.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: Is there any M3 port to Linux?


   Please can we have access to ALPHA/BETA code for evaluation / testing. I
   really want to get my hands on the Linux code to see what sort of 
   performance the compiler / runtime gives.

Well, you do. I dont have any special access to alpha/beta code.
I just keep looking around on gatekeeper.dec.com. There is a
directory named pub/DEC/Modula-3/alpha-3.0 which i downloaded
and somehow managed to modify and compile but could not get to run. While
the compiler has been used at DEC SRC for some months, the ports and
packaging are, as they are called, "alpha" (documentation missing, ports
incomplete...). Personally, i will wait for the next alpha/beta release and
as soon as i get something usable i will keep you posted.

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

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

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


======================================================================= 20 ===
Date:    Thu, 14 Oct 1993 15:44:49 +0000
From:    steve@rtal.demon.co.uk (Steve Callins)
Subject: Doctor Dobbs Article


I dont know how many of you have seen a copy of the October 
edition of Dr Dobbs. I was excited by their theme, but disappointed 
by the contents. Please see my following letter to the DDJ editor 
in chief.

Unless I am far wrong, with the exception of Eiffel, none of the 
alternative to C++ languages reviewed have any global popularity.

Ironically, when DDJ hit my desk, I was attending a major International 
Conference hosted by our Open University here in the UK. This was a 
workshop on the choice of programming languages. This was attended by 
over 100 people with speakers drawn from throughout the world. This 
conference best part mirrored the 'Beyond C++' DDJ thrust, but 
exemplifying an entirely different set of alternative languages that 
already have marketplace acceptance.

Amongst others, languages covered at this conference were:

C++
Modula-2 (pending ISO Standard)
Ada
Modula-3 (why did not Dobbs cover this?)
Extended Pascal (ISO Standard)
Oberon (see my letter)
Turing (from Canada)
Eiffel
Smalltalk
Lisp
Omega (from Austria)
CooL (from a huge pan european cooperative effort, backed by Siemens 
       in Germany)
Fortran 90 (ISO Standard)

All are basically OOP languages - why did not DDJ cover these too? 
Why do the editorial staff of DDJ not publish an accessible EMAIL address?

Any comments that you have about the above and enclosed would we welcome.


Steve Collins, RTA London.
----------------Enclosed Letter to Doctor Dobbs-------------------------
Jonathan Erickson
Editor in Chief
Dr. Dobb's Journal
411 Borel Ave
San Mateo
CA 94022-3522
USA                                                       13th October 1993

Dear Jonathan,

Re: DDJ October 1993 issue -  please  consider  the  following  for  letter
    publication 

It was good to see that DDJ has  finally  realised  that  there  are  other
programming languages in the world than C (and  its  derivatives),  and  so
your OOP language comparison feature was a welcome change. 

However, this was xenophobic to the extreme -  why  just  concentrate  upon
obscure 'made  in  the  USA'  languages  -  and  ignore  world  mainstream,
commercial language developments? 

After all, you must be aware that DDJ is now read Internationally,  and  so
it is a pity that you do not even bother to investigate - let alone  report
- on what is happening outside of California. 

As an example, why not report on Oberon-2 language developments?  It  is  a
fine, small and application versatile OOP language. It also has the Niklaus
Wirth / ETH language and commercial acceptance heritage  -  Algol,  Pascal,
Modula-2, and now Oberon-2. Did you know that NASA use Oberon-2? 

If you would like a well balanced article, on OOP developments then I will
happily  contribute.


With best regards,



Steve Collins
(Managing Director)

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

-- 
 ----------------------------------------------------------
 Steve Collins                    steve@rtal.demon.co.uk
 Managing Director                71333.2346@compuserve.com

 Real Time Associates Ltd         CompuServe: 71333,2346
 Canning House, 59 Canning Road   Tel: (+44) (0)81 656 7333
 Croydon, Surrey, CRO 6QF, UK     Fax: (+44) (0)81 655 0401
 ----------------------------------------------------------


======================================================================= 21 ===
Date:    14 Oct 1993 18:17:26 GMT
From:    pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
Subject: Re: Doctor Dobbs Article


>Amongst others, languages covered at this conference were:
>
>C++
>Modula-2 (pending ISO Standard)
>Ada
>Modula-3 (why did not Dobbs cover this?)
>Extended Pascal (ISO Standard)
>Oberon (see my letter)
>Turing (from Canada)
>Eiffel
>Smalltalk
>Lisp
>Omega (from Austria)
>CooL (from a huge pan european cooperative effort, backed by Siemens 
>       in Germany)
>Fortran 90 (ISO Standard)
>
>All are basically OOP languages - why did not DDJ cover these too? 

You're wrong. I don't know about Turing, Omega, and CooL, but Modula-2,
Ada-83, Extended Pascal, and Lisp are *not* OOP languages. They are at
most OOB languages - and Lisp isn't even that.

Although there is no real consensus about the term `object oriented',
there are some generally accepted definitions. One of the best known
ones ist that of [CW85]:
"... a language is object-oriented if and only if it satisfies the
following requirements:

 - It supports objects that are data abstractions with an interface of
   named operations and a hidden local state.
 - Objects have an associated type.
 - Types may inherit attributes from supertypes."

Another point: why are so many people who use `lesser known programming
languages' (which includes me, too) so zealous about propagating their
language? Why don't we just do what we're having fun in and look what
becomes of the others?

Peter

[CW85] L. Cardelli and P. Wegner.  On Understanding Types, Data
       Abstraction, and Polymorphism.  ACM Computing Surveys vol. 17 (4),
       pp. 471-520 (1985}

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




======================================================================= 22 ===
Date:    Thu, 14 Oct 1993 15:57:34 -0400
From:    Dick Orgass <do12+@andrew.cmu.edu>
Subject: Re: SRC Modula-3 for IBMR2 / RS6000

I did the original port of SRC Modula-3 to a RISC/6000 when I was still
with IBM.  The last version that I had fully running was 2.05 and it
seemed to work just fine, including Trestle and all the other "friends".

Several people at IBM Research continued working on Modula-3 and I hope
the will provide you with additional information.

Dick


======================================================================= 23 ===
Date:    14 Oct 1993 21:37:28 GMT
From:    mw@ipx2.rz.uni-mannheim.de (Marc Wachowitz)
Subject: Re: Doctor Dobbs Article

Peter Klein (pk@rwthi3.informatik.rwth-aachen.de) wrote:
: Ada-83, Extended Pascal, and Lisp are *not* OOP languages. 
: They are at most OOB languages - and Lisp isn't even that.

Oh, CLOS (Common Lisp Object System) is not object oriented?

:  - It supports objects that are data abstractions with an interface of
:    named operations and a hidden local state.
Supported by CLOS; encapsulation is done with packages.
[You could break it by use of low-level functionality, but I consider that
 similar to taking storage addresses in other languages - useful for a few
 cases in systems programming, but to avoided elsewhere.]

:  - Objects have an associated type.
Supported by CLOS.

:  - Types may inherit attributes from supertypes."
Supported by CLOS.

Btw, CLOS is part of the (draft) ANSI standard for Lisp.

In addition, there are many other Lisp variants with different ways
supporting oop (according to the above definitions).

------------------------------------------------------------------------------
   *   wonder everyday   *   nothing in particular   *   all is special   *
                Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>


======================================================================= 24 ===
Date:    15 Oct 1993 11:58:20 GMT
From:    pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
Subject: Re: Doctor Dobbs Article


>Peter Klein (pk@rwthi3.informatik.rwth-aachen.de) wrote:
>: Ada-83, Extended Pascal, and Lisp are *not* OOP languages. 
>: They are at most OOB languages - and Lisp isn't even that.
>
>Oh, CLOS (Common Lisp Object System) is not object oriented?
>

Of course, CLOS is OO. But the intention of my posting was to put
terminology right. If we are talking about Lisp, we generally don't
mean CLOS. If we are talking about Modula-2, we don't mean any
draft of some proposal which might include OO features in the
future. If we are talking about object oriented, we don't mean
object based. That's all.

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




======================================================================= 25 ===
Date:    15 Oct 1993 14:23:52 GMT
From:    info@xinotech.com (Brian Hanson)
Subject: Re: Doctor Dobbs Article


> You're wrong. I don't know about Turing, Omega, and CooL, but Modula-2,
> Ada-83, Extended Pascal, and Lisp are *not* OOP languages. They are at
> most OOB languages - and Lisp isn't even that.
There is now Ada 9X which is as much object oriented as c++.  You can
even
get an ada 9x compiler (gnu ada or gnat) for sun sparc and os2 via ftp.


======================================================================= 26 ===
Date:    Fri, 15 Oct 1993 20:57:33 GMT
From:    papresco@undergrad.math.uwaterloo.ca (Paul Prescod)
Subject: Re: Doctor Dobbs Article

In article <29k53m$78t@urmel.informatik.rwth-aachen.de>,

>Another point: why are so many people who use `lesser known programming
>languages' (which includes me, too) so zealous about propagating their
>language? Why don't we just do what we're having fun in and look what
>becomes of the others?
>
>Peter

1.If they are popular our bosses will let us use them.
2.They will have optimizing compilers.
3.They will be on more platforms so our code is more portable.
4.There will be more cool tools released for them.
5.We won't have to work with "existing code" in other languages.
6.We won't have to use interfaces to C-geared OS and tool features.
7.A market gives rise to competition.  Competition gives rise to better 
	products.
8.We won't have to work with rotten apps that seg fault because of pointer 
    violations.
9.We wouldn't want the product to get cancelled due to lack of interest (this
    has happened to many languages)
10.We feel sorry for the poor fools who don't know any better.


Paul Prescod



======================================================================= 27 ===
Date:    Fri, 15 Oct 1993 15:06:39 GMT
From:    george@bcstec.ca.boeing.com (Harry G. George)
Subject: DDJ article (short)

Here is how M3 would look for the DDJ example.
See "DDJ article (long)" for the supporting modules.

MODULE tstlist EXPORTS Main;
(*
Public Domain, No Rights Reserved.
Abstract:  Singly linked list, to demonstrate M3 code
           Per Dr. Dobbs Journal, 18(11):118-125, Oct 1993

9/8/93     H. George
           Initial version
*)

IMPORT Wr,Stdio,MyList,Geometry;

VAR
  list1:=NEW(MyList.T).init();
  list2:=NEW(MyList.T).init();
  n1:=NEW(Geometry.Number).init(10);
  n2:=NEW(Geometry.Number).init(20);
  p1:=NEW(Geometry.Point).init(2,3);
  p2:=NEW(Geometry.Point).init(4,5);
  
  
BEGIN
  (*build the lists*)
  list1.AddToList(n1);
  list1.AddToList(n2);
  list1.AddToList(p1);
  list2.AddToList(n2); (*an object can be in more than one list*)
  list2.AddToList(p1); (*at the same time*)
  list2.AddToList(p2);
  list2.AddToList(list1); (*we can even put a list into another list*)

  (*print the lists*)
  Wr.PutText(Stdio.stdout,"\nlist1:\n");
  list1.print();
  Wr.PutText(Stdio.stdout,"\nlist2:\n");
  list2.print();

  (*Note that garbage collector cleans up -- no deletes needed*)
  (*even if we weren't exiting the whole program at this point*)
END tstlist.

---------------------------------------------------------
Disclaimer:  Any opinions expressed herein are my own and
             not those of The Boeing Company.
Contact:     Harry George, BCAG Automated Software Analysis  
Phone:       (206) 237-6915  Org: 6-6541  M-S: 6A-UA
E-mail:      george@garden.ca.boeing.com
IP address:  137.137.45.51                     


======================================================================= 28 ===
Date:    Fri, 15 Oct 1993 14:59:31 GMT
From:    george@bcstec.ca.boeing.com (Harry G. George)
Subject: DDJ article (long)

The day I saw the DDJ article, I wrote up a Modula-3 treatment.
But I didn't want to send it, because I didn't know if this
was the best/most appropriate idiom.  Obviously, it
is more verbose than some of the examples in the
article - of course we think of that as self-documenting :-).

Maybe someone who know the language better than I could rework
this and submit it.  In particular, it probably ought to make 
use of exceptions.
 
==========================================
INTERFACE Geometry;
(*
Public Domain, No Rights Reserved.
Abstract:  Geometry for singly linked list, to demonstrate M3 code
           Per Dr. Dobbs Journal, 18(11):118-125, Oct 1993.

9/8/93     H. George
           Initial version. 
*)

IMPORT MyList;

TYPE

  Number    <: PublicNumber;
  PublicNumber =
               MyList.Data BRANDED OBJECT
	       METHODS
	         init(initialValue:INTEGER:=0):Number;
	       END;

  (*-------------------*)
  Point     <: PublicPoint;
  PublicPoint= MyList.Data BRANDED OBJECT
	       METHODS
	         init(initialX,initialY:INTEGER:=0):Point;
	       END;
END Geometry.
===========================================
MODULE Geometry;
(*
Public Domain, No Rights Reserved.
Abstract:  Geometry for singly linked list, to demonstrate M3 code
           Per Dr. Dobbs Journal, 18(11):118-125, Oct 1993.

9/8/93     H. George
           Initial version.
*)
IMPORT Wr,Stdio,Fmt,MyList;

REVEAL

  Number     = PublicNumber BRANDED OBJECT
                 value:INTEGER;
	       METHODS
	       OVERRIDES
                 init:=InitNumber;
	         print:=PrintNumber;
	       END;
  
  Point      = PublicPoint BRANDED OBJECT
                 x,y:INTEGER;
	       METHODS
	       OVERRIDES
                 init:=InitPoint;
	         print:=PrintPoint;
	       END;
  

(*-----------------*)
PROCEDURE InitNumber(self        :Number; 
	             initialValue:INTEGER:=0
		                ):Number = 
BEGIN
  self.value:=initialValue;
  RETURN self;
END InitNumber;
(*-----------------*)
PROCEDURE PrintNumber(self:Number) =
BEGIN
  Wr.PutText(Stdio.stdout,"Number: "&Fmt.Int(self.value)&"\n");
END PrintNumber;

(*-----------------*)
PROCEDURE InitPoint(self             :Point; 
	            initialX,initialY:INTEGER:=0
		                    ):Point = 
BEGIN
  self.x:=initialX;
  self.y:=initialY;
  RETURN self;
END InitPoint;
(*-----------------*)
PROCEDURE PrintPoint(self:Point) =
BEGIN
  Wr.PutText(Stdio.stdout,"Point: " & Fmt.Int(self.x) & "," 
                                    & Fmt.Int(self.y) & "\n");
END PrintPoint;


(*================*)
BEGIN
END Geometry.
===============================================
INTERFACE MyList;
(*
Public Domain, No Rights Reserved.
Abstract:  Singly linked list, to demonstrate M3 code
           Per Dr. Dobbs Journal, 18(11):118-125, Oct 1993.

9/8/93     H. George
           Initial version.
*)

TYPE
  (*In each case, the C++ "public" stuff  is visible in
  **the PublicXyz object, while the "private" stuff is
  **hidden in its opaque subtyp. Clients use the subtypes.
  *) 
 
  (*-------------------*)
  Data      <: PublicData;
  PublicData = OBJECT
               METHODS
                 print();
	       END;
  (*-------------------*)
  Element   <: PublicElement;
  PublicElement =
               OBJECT
               METHODS
                 init(initialData:Data:=NIL;
                             next:Element:=NIL
			        ):Element;
               END;

  (*-------------------*)
  T         <: PublicT;
  PublicT    = Data BRANDED OBJECT
	       METHODS
	         init():T;
		 AddToList(data:Data);
	       END;

END MyList.
================================================
MODULE MyList;
(*
Public Domain, No Rights Reserved.
Abstract:  Singly linked list, to demonstrate M3 code
           Per Dr. Dobbs Journal, 18(11):118-125, Oct 1993.

9/8/93     H. George
           Initial version.
*)
IMPORT Wr,Stdio,Fmt;

REVEAL

  Data       = PublicData BRANDED OBJECT
               OVERRIDES
                 print:=PrintData;
               END;

  Element    = PublicElement BRANDED OBJECT
                 data: Data:=NIL;
                 next: Element:=NIL;
               OVERRIDES
	         init:=InitElement; 
	       END; 

  T          = PublicT BRANDED OBJECT
                 head,tail:Element:=NIL;
               OVERRIDES
	         init:=InitT; 
		 AddToList:=AddToListT;
                 print:=PrintT;
	       END; 



(*-----------------*)
PROCEDURE PrintData(self:Data) = 
BEGIN
  Wr.PutText(Stdio.stdout,"No print method!\n");
END PrintData;

(*-----------------*)
PROCEDURE InitElement(self       :Element;
                      initialData:Data:=NIL;
		      next       :Element:=NIL
                                ):Element =
BEGIN
  self.data:=initialData;
  self.next:=next;
  RETURN self;
END InitElement;
(*-----------------*)
PROCEDURE InitT(self:T):T =
BEGIN
  self.head:=NIL;
  self.tail:=NIL;
  RETURN self;
END InitT;
(*-----------------*)
PROCEDURE AddToListT(self:T;  
	             data:Data) = 
VAR
  newElement:Element:=NEW(Element).init(data);
BEGIN
  IF (self.head = NIL) OR (self.tail=NIL) THEN
    self.head:=newElement;
    self.tail:=newElement;
  ELSE
    self.tail.next:=newElement;
    self.tail:=newElement;
  END;
END AddToListT;
(*-------------------*)
PROCEDURE PrintT(self:T) =
VAR
  element:Element;
BEGIN
  element:=self.head;
  WHILE element # NIL DO
    IF (element.data#NIL) THEN
       element.data.print();
    ELSE
      Wr.PutText(Stdio.stdout,"NIL list member\n");
    END;
    element:=element.next;
  END;
END PrintT;
(*================*)
BEGIN
END MyList.
=============================================
[output]
# tstlist

list1:
Number: 10
Number: 20
Point: 2,3

list2:
Number: 20
Point: 2,3
Point: 4,5
Number: 10
Number: 20
Point: 2,3
---------------------------------------------------------
Disclaimer:  Any opinions expressed herein are my own and
             not those of The Boeing Company.
Contact:     Harry George, BCAG Automated Software Analysis  
Phone:       (206) 237-6915  Org: 6-6541  M-S: 6A-UA
E-mail:      george@garden.ca.boeing.com
IP address:  137.137.45.51                     





======================================================================= 29 ===
Date:    16 Oct 1993 14:16:14 GMT
From:    kubla@bianca.zdv.Uni-Mainz.DE (Dominik Kubla)
Subject: Re: Doctor Dobbs Article

: >Peter Klein (pk@rwthi3.informatik.rwth-aachen.de) wrote:
: >: Ada-83, Extended Pascal, and Lisp are *not* OOP languages. 
: >: They are at most OOB languages - and Lisp isn't even that.
: >
: >Oh, CLOS (Common Lisp Object System) is not object oriented?
: >

But ADA was part of the DDJ comparison! So if they look at ADA, then
there is no argument against checking Modula-2 or Oberon. Since they did
not even mentioned those languages, the initial remarks of being a bit
narrowminded still holds. BTW Oberon-2 is definitely OO.

--
Cheers,
  Dominik

+---------------------------------------------------------------------------+
| eMail: kubla@goofy.zdv.Uni-Mainz.DE                                       |
| sMail: Dominik Kubla, Steinsberg 34, 56355 Nast\"atten, F. R. Germany     |
+---------------------------------------------------------------------------+
|                                                                           |
|        "Linux: The choice of a GNU generation"      --S. Frampton         |
|                                                                           |
+---------------------------------------------------------------------------+
DISCLAIMER:  Everything written above are the expressed thoughts of the
author and in no way connected to 'Johannes Gutenberg Universit\"at', Mainz
(Germany). This way, they do not have to care about what I say ...


======================================================================= 30 ===
Date:    16 Oct 1993 16:47:59 GMT
From:    pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
Subject: Re: Doctor Dobbs Article

kubla@bianca.zdv.Uni-Mainz.DE (Dominik Kubla) writes:

>But ADA was part of the DDJ comparison! So if they look at ADA, then
>there is no argument against checking Modula-2 or Oberon. Since they did
>not even mentioned those languages, the initial remarks of being a bit
>narrowminded still holds. BTW Oberon-2 is definitely OO.
>

The Doctor Dobbs article was about object-oriented programming languages.
Why should they mention Modula-2 there? They didn't mention Oberon, which
is European. But they also didn't mention Modula-3, which is American.
And how about Smalltalk, Fortran-90, and CLOS?

We should keep in mind that the usage of *all* object-oriented languages
is pretty negligible compared to Fortran, Cobol, and C. And amongst the
OOPLs, C++ has definitely the greatest popularity. Personally, I think
this is regrettable, but it's true.

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




======================================================================= 31 ===
Date:    16 Oct 1993 21:13:24 GMT
From:    mbk%anl433.uucp@Germany.EU.net (Matt Kennel)
Subject: Re: Doctor Dobbs Article

Peter Klein (pk@rwthi3.informatik.rwth-aachen.de) wrote:
: kubla@bianca.zdv.Uni-Mainz.DE (Dominik Kubla) writes:

: >But ADA was part of the DDJ comparison! So if they look at ADA, then
: >there is no argument against checking Modula-2 or Oberon. Since they did
: >not even mentioned those languages, the initial remarks of being a bit
: >narrowminded still holds. BTW Oberon-2 is definitely OO.
: >

: The Doctor Dobbs article was about object-oriented programming languages.
: Why should they mention Modula-2 there? They didn't mention Oberon, which
: is European. But they also didn't mention Modula-3, which is American.
: And how about Smalltalk, Fortran-90, and CLOS?

Remember; the articles were written by different people, one for
each language.  I.e. they probably couldn't get somebody to write articles
for other languages in time.  

Smalltalk?  People know about it already. F-90? No.  CLOS?  Too slow.

Modula-3 and Oberon are the big omissions.

I would have preferred less emphasis on some of those
Windows/PC-centric/C-oid/non-garbage-collecting things which seem like a
dumb idea.  

I'm personally rooting for Sather, followed by Eiffel and then M3.

: Peter

--
-Matt Kennel  		mbk@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".


======================================================================= 32 ===
Date:    17 Oct 93 00:10:44 GMT
From:    peju@alice.att.com (Peter Juhl)
Subject: Re: Doctor Dobbs Article



Just one small fact, Dr Dobbs allready ran an article on 
Modula3, less than a year ago. So if you subscribe then    
you allready know about Modula3 (or a least you should)

The Modula3 article was written by Sam Harbison.

--- peter (peju@research.att.com)


======================================================================= 33 ===
Date:    Sun, 17 Oct 1993 12:38:51 GMT
From:    pgs1002@cus.cam.ac.uk (Dr P.G. Sjoerdsma)
Subject: M3 vs Oberon capabilities

Can someone tell me what the basic differences are between Modula-3
and Oberon and especially concerning OOP. I've done a lot of
programming in C,C++ mainly because I wanted to write graphical
simulation programs and the acces to the libraries (X11, Xview,
Sunview etc) was up to date when using C and C++. Meanwhile C++ is becoming
way to big for me. Just look at the comp.lang.c++, it's like they were
born on a different planet. Most of my programs are in C++ and are
based on OOP and X11R4-Xview. How easy is it to convert things. Do
Modula-3 and/or Oberon support operator-overloading etcetera. How good
is there graphical capability. I read about Trestle for M3 but is it
worth it? What are the graphical interfaces for Oberon?? 




Thanks in advance for all the information.
(personal e-mail is ok)


Paul
--
                                 ___
                                (o o) 
-----------------------------ooO-(_)-Ooo-----------------------------
        Paul Sjoerdsma, Godwin Laboratory, Free School Lane,
                     Cambridge CB2 3RS England
       fax:   (44) (0)223-334871, email: pgs1002@cus.cam.ac.uk
---------------------------------------------------------------------





======================================================================= 34 ===
Date:    Sun, 17 Oct 1993 22:31:45 GMT
From:    kirschnt@informatik.uni-muenchen.de (Torsten R. Kirschner)
Subject: Q: M3 alpha-3.0 on axposf.pa.de.com

Hello,

is there a chance that M3 alpha-3.0 gets installed on axposf.ps.de.com?
[For those who don't know: axposf is a publicly accessible DEC Alpha.]

I tried to install the compiler, but while I can compile it without
any problems, I cannot get it installed. [The install scripts claim
that some chgrp doesn't work. Well, I don't want to chgrp to anything
at all in the first place...] However, that's more than I achieved on 
other platforms, even DS3100.

I would be happy to get a look at a snapshot of 3.0 on DEC Alpha OSF/1.
Couldn't someone at SRC who's working at it put a copy of it on axposf,
please?

Thanks in advance for any comments,
Torsten
-- 
Torsten R. Kirschner          Torsten.R.Kirschner@informatik.tu-muenchen.de


======================================================================= 35 ===
Date:    Mon, 18 Oct 1993 10:59:08 GMT
From:    ross@mama.minmet.uq.oz.au (Ross Cottrell)
Subject: Re: Doctor Dobbs Article

kubla@bianca.zdv.Uni-Mainz.DE (Dominik Kubla) writes:

>But ADA was part of the DDJ comparison! So if they look at ADA, then
>there is no argument against checking Modula-2 ...

You must be joking.  Compared to ADA, Modula-2's support for data
data abstraction is pitiful.  You don't have OO without data abstraction!


Regards, Ross.



======================================================================= 36 ===
Date:    Mon, 18 Oct 1993 03:23:54 GMT
From:    whitney@oberon.Meakins.McGill.CA ()
Subject: Re: Doctor Dobbs Article

Peter Moylan (peter@laplace.newcastle.edu.au) wrote:

: I've been wondering whether we'll gain much by the addition
: of OO features to Modula-2.  I use a compiler (TopSpeed) which
: supports some OO extensions, and so far I've failed to find
: anything useful to do with those extensions.  I've looked at
: the possibility of re-designing some of my modules using an
: OO approach, but every time I'm stopped by a nasty problem:
: I can't do it without making public some things that I think
: ought to be kept private.

This is a problem with export control not extensibility.
In fact you can have extensibility without exporting
fields of an object. The mechanics of extensibility is
acheived by passing the required information such as the 
size of records, the offset of exported fields through 
symbol files.

Eg. Pseudo Modula-2

IMPLEMENTATION MODULE M0;

PUBLIC TYPE
	(* export Object, ObjectRecord *)
	Object = POINTER TO ObjectRecord;
	ObjectRecord = RECORD
		PRIVATE
		x,y : INTEGER;
		PUBLIC 
		z : INTEGER;
	END;
TYPE
	PrivateRecord = RECORD
		x : INTEGER; 
	END;

PUBLIC PROCEDURE Do( obj : Object );
BEGIN
END Do;

END MODULE M0.

Note: This would require that symbol files be generated from a mixture
of definition and implementation modules rather than just definition
modules as is the case for Modula-2.  There is not enough
information in the definiton modules to determine the offsets 
of fields, record sizes, etc as required by OOP.

BTW, Other languages such as Oberon ( a successor to Modula-2 )
have a single source which used to generate *.Sym and *.Obj files. 
Definition modules are also generated. They are not written 
by the programmer. They are not used for documentation but
serve as on-line references for the programmer familiar
with the design of the module. 

Here is the "generated" definition module for the module
above.

DEFINITION MODULE M0;

TYPE
	Object = POINTER TO ObjRecord;
	ObjectRecord = RECORD
		z : INTEGER;
	END;

PROCEDURE Do( obj : Object );


END M0.


======================================================================= 37 ===
Date:    18 Oct 1993 07:04:41 GMT
From:    mw@ipx2.rz.uni-mannheim.de (Marc Wachowitz)
Subject: Re: Doctor Dobbs Article

Peter Moylan (peter@laplace.newcastle.edu.au) wrote:
: whitney@oberon.Meakins.McGill.CA wrote:
: >BTW, Other languages such as Oberon ( a successor to Modula-2 )
: >have a single source which used to generate *.Sym and *.Obj files. 
: >Definition modules are also generated. They are not written 
: >by the programmer. They are not used for documentation but
: >serve as on-line references for the programmer familiar
: >with the design of the module. 
:
: That's a step backwards, in my opinion.  The automatic generators
: strip out the comments.  What good is a definition module
: without comments?

I think the problem here is not that the merge of definition and 
implementation were a bad thing, but the lack of a sufficiently clever
documentation tool. What I'd like to see is a convention how to attach
public comments to declared entities (including the whole module), which
would then be extracted by the browser. There would probably have to be
some restrictions on comment formatting, but e.g. choosing between either
one-line comments or block comments on lines of their own would be ok.
This way you could also embed some other information for automatic cross
referencing, like the 'index' entries in Eiffel.


------------------------------------------------------------------------------
   *   wonder everyday   *   nothing in particular   *   all is special   *
                Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>


======================================================================= 38 ===
Date:    Mon, 18 Oct 1993 01:11:43 GMT
From:    peter@laplace.newcastle.edu.au (Peter Moylan)
Subject: Re: Doctor Dobbs Article

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

>We should keep in mind that the usage of *all* object-oriented languages
>is pretty negligible compared to Fortran, Cobol, and C. And amongst the
>OOPLs, C++ has definitely the greatest popularity. Personally, I think
>this is regrettable, but it's true.

And among the C++ users, very few do any OO programming.  They
use C++ because it's the latest version of C, not for any
other reason.

I've been wondering whether we'll gain much by the addition
of OO features to Modula-2.  I use a compiler (TopSpeed) which
supports some OO extensions, and so far I've failed to find
anything useful to do with those extensions.  I've looked at
the possibility of re-designing some of my modules using an
OO approach, but every time I'm stopped by a nasty problem:
I can't do it without making public some things that I think
ought to be kept private.

--
Peter Moylan                     peter@tesla.newcastle.edu.au


======================================================================= 39 ===
Date:    Mon, 18 Oct 1993 05:59:12 GMT
From:    peter@laplace.newcastle.edu.au (Peter Moylan)
Subject: Re: Doctor Dobbs Article

whitney@oberon.Meakins.McGill.CA wrote:
>Peter Moylan (peter@laplace.newcastle.edu.au) wrote:

>: I've been wondering whether we'll gain much by the addition
>: of OO features to Modula-2.  I use a compiler (TopSpeed) which
>: supports some OO extensions, and so far I've failed to find
>: anything useful to do with those extensions.  I've looked at
>: the possibility of re-designing some of my modules using an
>: OO approach, but every time I'm stopped by a nasty problem:
>: I can't do it without making public some things that I think
>: ought to be kept private.

>This is a problem with export control not extensibility.
>In fact you can have extensibility without exporting
>fields of an object. The mechanics of extensibility is
>acheived by passing the required information such as the 
>size of records, the offset of exported fields through 
>symbol files.

I agree - but the sort of ideas I've seen thrown around for
OO extensions for M2 don't seem to be headed that way.
Everyone seems to think that you can't have inheritance unless
the parent class is fully elaborated in the definition module.

Of course you could start using keywords like PUBLIC and
PRIVATE in the definition module, but I don't think that's an
adequate solution.  The visibility rules could easily turn
into the sort of baroque mess you have in C++, especially
if the concept of "static members" is included.

I much prefer what you're suggesting [example deleted],
though I think it ought to be carried a little further: put
the visible members in the definition module, and the
hidden ones in the implementation module.

>Note: This would require that symbol files be generated from a mixture
>of definition and implementation modules rather than just definition
>modules as is the case for Modula-2.  There is not enough
>information in the definiton modules to determine the offsets 
>of fields, record sizes, etc as required by OOP.

Oh, if only the standard would allow that!  Not so much because
I want OOP, but because it would at last remove the stupid
rule about opaque types having to be pointers.

There's a catch, though: to make this work, you might have to
ban circular dependencies among modules.  (Not just circularities
in the definition modules - these are already banned - but
circularities involving the implementation modules.)  That
wouldn't bother me, since I believe that a circularity in
imports is a priori evidence of a design error, but apparently
it would bother some people.  The new M2 standard takes care to
define the order of execution of initialisation parts, and
that's a detail that it shouldn't be necessary to specify
_unless_ you write programs with circular dependencies.
Furthermore, the new standard I/O library modules are specified
in such a way that, as far as I can tell, they are fundamentally
impossible to implement unless you allow a circular dependency.

>BTW, Other languages such as Oberon ( a successor to Modula-2 )
>have a single source which used to generate *.Sym and *.Obj files. 
>Definition modules are also generated. They are not written 
>by the programmer. They are not used for documentation but
>serve as on-line references for the programmer familiar
>with the design of the module. 

That's a step backwards, in my opinion.  The automatic generators
strip out the comments.  What good is a definition module
without comments?

On the other hand, Oberon does teach us one valuable lesson:
with type extensibility, you can get the advantages of
OOP without actually having to go down the OOP path.

--
Peter Moylan                     peter@tesla.newcastle.edu.au


======================================================================= 40 ===
Date:    Mon, 18 Oct 1993 12:37:53 +0000
From:    ian@rtal.demon.co.uk (Ian Marshall)
Subject: Re: Doctor Dobbs Article 

In article <1993Oct18.055912.5789@seagoon.newcastle.edu.au> peter@tesla.newcast
le.edu.au writes:

>That's a step backwards, in my opinion.  The automatic generators
>strip out the comments.  What good is a definition module
>without comments?

This is completely implementation dependant. For example, our Extacy
Oberon-2 implementation (latest release) will now keep selected comments
in the pseudo-definition module. You also have a certain degree of control
of ordering. For example, in other browsers I have seen (including earlier
versions of our own) the order of the pseudo-def was alphabetic (mostly
because the symbol file is arranged this way). I always found this 
irritating as I grouped definitions according to relation of use.

>On the other hand, Oberon does teach us one valuable lesson:
>with type extensibility, you can get the advantages of
>OOP without actually having to go down the OOP path.

I don't see what you mean. Oberon (or at least Oberon-2) is definitely
object-oriented. Only the 'standard' jargon has been removed. Replace
'type extension' with 'inheritance' (as it is the same thing) and you
have 'object-oriented' jargon and functionality.

-- 
-------------------------------------------------------------------------
Ian Marshall,
Real Time Associates Ltd,          Tel        : (+44)(0)81 656 7333/4/5
Canning House, 59 Canning Road,    Fax        : (+44)(0)81 655 0401
Croydon,Surrey,CR0 6QF             Email      : ian@rtal.demon.co.uk
UK                                 Compuserve : 71333,2456      
-------------------------------------------------------------------------


======================================================================= 41 ===
Date:    18 Oct 1993 12:52:08 GMT
From:    dat93rli@ludat.lth.se (Rune Lindman)
Subject: Modula 3 for Macintosh

Is there a Modula 3 compiler for the Macintosh series?



======================================================================= 42 ===
Date:    Mon, 18 Oct 1993 11:33:41 +0000
From:    ian@rtal.demon.co.uk (Ian Marshall)
Subject: Re: Doctor Dobbs Article 

In article <29po5kINNlqi@network.ucsd.edu> mbk%anl433.uucp@Germany.EU.net write
s:


>Remember; the articles were written by different people, one for
>each language.  I.e. they probably couldn't get somebody to write articles
>for other languages in time.  

I doubt this very much. This edition was definitely not a one month 
project.

>
>Smalltalk?  People know about it already. 
>

But introducing new languages wasn't necessarily the aim of the articles.

>I would have preferred less emphasis on some of those
>Windows/PC-centric/C-oid/non-garbage-collecting things which seem like a
>dumb idea.  

I agree, but unfortunately they're very much the 'in thing'. Unlike
skateboards, however, I think they'll take a while to die.

--
-------------------------------------------------------------------------
Ian Marshall,
Real Time Associates Ltd,          Tel        : (+44)(0)81 656 7333/4/5
Canning House, 59 Canning Road,    Fax        : (+44)(0)81 655 0401
Croydon,Surrey,CR0 6QF             Email      : ian@rtal.demon.co.uk
UK                                 Compuserve : 71333,2456      
-------------------------------------------------------------------------


======================================================================= 43 ===
Date:    Mon, 18 Oct 1993 12:23:28 +0000
From:    ian@rtal.demon.co.uk (Ian Marshall)
Subject: Re: Doctor Dobbs Article 

In article <1993Oct18.011143.2328@seagoon.newcastle.edu.au> peter@tesla.newcast
le.edu.au writes:

>And among the C++ users, very few do any OO programming.  They
>use C++ because it's the latest version of C, not for any
>other reason.

Not quite. I agree with the fact that they do little OO stuff, basically
because to so many C->C++ converts, encapsulation and generally correct
abstraction is something that only happens to everybody else. I think 
that OO programming is often too 'academic' to people who have not been
using C properly. These people do, however, use the additional features
of C++ such as function overloading and much of the other aspects of
(non-inheritance) polymorphism. It odd to see such a powerful tool wasted
in the hands of so many.

Please, however, never make the mistake of generalising C++ programmers
in this way. Many (probably most, now) do use the language properly and
to its full extent.

>                          I use a compiler (TopSpeed) which
>supports some OO extensions, and so far I've failed to find
>anything useful to do with those extensions.  I've looked at
>the possibility of re-designing some of my modules using an
>OO approach, but every time I'm stopped by a nasty problem:
>I can't do it without making public some things that I think
>ought to be kept private.

Oddly enough, to a certain extent the OO features of TopSpeed are
pulled from the general ideas of C++'s OO features. They are almost
as useful as the C++ approach. The difficulties you are having are 
probably related to TopSpeeds 2 levels of protection against C++'s
3 levels, and also the difficulties of having separate header and body
for classes.
-- 
-------------------------------------------------------------------------
Ian Marshall,
Real Time Associates Ltd,          Tel        : (+44)(0)81 656 7333/4/5
Canning House, 59 Canning Road,    Fax        : (+44)(0)81 655 0401
Croydon,Surrey,CR0 6QF             Email      : ian@rtal.demon.co.uk
UK                                 Compuserve : 71333,2456      
-------------------------------------------------------------------------


======================================================================= 44 ===
Date:    Mon, 18 Oct 1993 16:37:03 GMT
From:    hendrik@vedge.com (Hendrik Boom)
Subject: Re: Why structural equivalence?

mbk%anl433.uucp@Germany.EU.net (Matt Kennel) writes:
: 
: It also goes against the "spirit" of the concept of a named type. (You
: gave it a name for a reason).

When I talk about real numbers, I often use names like x and y,
without implying either that x = y or that x /= y. If I need distinct
numbers, I make sure they are different by other means than using
different names.  If use of different names implied distinctness of value,
I would find all kinds of theorems like, given real x and y, x - y /= 0.
This would greatly complicate mathematics.

I do not see why the situation should be different for types.
When reasoning about programs, performing program transformations, etc.,
one frequently copies code, renames bound variables, etc.  This can
be dome with types, too, just like variables in algebra.

I am pleased that, unlike Pascal and many other languages, modula 3
distinguishes between branding and naming.
If I need them distinct, modula 3 provides convenient means
of ensuring that they are so.

-- 
-------------------------------------------------------
Try one or more of the following addresses to reply.
at work:	hendrik@vedge.com,  iros1!vedge!hendrik
at home:	uunet!ozrout!topoi!hendrik


======================================================================= 45 ===
Date:    19 Oct 93 01:43:48 GMT
From:    blaak@csri.toronto.edu (Raymond Blaak)
Subject: Re: Why structural equivalence?

hendrik@vedge.com (Hendrik Boom) writes:

>mbk%anl433.uucp@Germany.EU.net (Matt Kennel) writes:
>: 
>: It also goes against the "spirit" of the concept of a named type. (You
>: gave it a name for a reason).

>...If use of different names implied distinctness of value,
>I would find all kinds of theorems like, given real x and y, x - y /= 0.
>This would greatly complicate mathematics.

>I do not see why the situation should be different for types.
>When reasoning about programs, performing program transformations, etc.,
>one frequently copies code, renames bound variables, etc.  This can
>be dome with types, too, just like variables in algebra.

My problem with structural equivalence is the hidden surprises. If I have two
records with fields of identical types, but with different semantic meanings,
then by default I prefer to have them treated as distinct unless explicitly
stated otherwise.

I feel safer when the only operations on a type are those explicitly stated,
for then the compiler will catch by default any silly mistakes I make (e.g.
passing the wrong type of parameter to a procedure).

If I want do describe an algorithm in a type independent way I should build as
such explicitly (e.g. via templates or generics, or providing a set of common
overloaded operators for a group of types as in algebra, or inheriting from a
common parent, etc.).

The point is that the only things allowed are those specifically stated. If it
is not said, it doesn't happen. In my opinion, this leads to less bugs because
of less unexpected surprises.

As for reasoning about programs, the programs being reasoned about then
become the data, and appropriate types and their operators should be defined
to properly state what can and cannot be done when doing such reasoning. 

Given my preference, if I am to program in Modula-3 I would brand everything
unless I specifically needed structural equivalence.

Please note I am not particularly knocking Modula-3 here, but rather
responding to the structural equivalence thread.

Cheers,
Ray
blaak@csri.toronto.edu


======================================================================= 46 ===
Date:    18 Oct 1993 21:35:11 GMT
From:    crawford@boole.mitre.org (Randy Crawford)
Subject: Re: M3 vs Oberon capabilities


In article <PGS1002.93Oct17133843@apus.cus.cam.ac.uk>, pgs1002@cus.cam.ac.uk (D
r P.G. Sjoerdsma) writes:
> Can someone tell me what the basic differences are between Modula-3
> and Oberon and especially concerning OOP. 

Oberon is a version of Modula2 without several of the data types and
operators that Wirth thought were largely uneeded by most programmers 
(and sometimes hard to implement).  Oberon is a subset of Modula2, 
and if M2 is not an OOPL (which it's not) then neither is Oberon.
Modula3 adds single inheritance and simple polymorphism.  I believe
that operator overloading is not supported (which is fine by me).

I've heard tell that some sort of extended variant of Oberon exists
which *is* an OOPL, but good luck to you finding a compiler.  Better
to stick with M3 if you feel Modulish.  IMHO, Oberon's heyday is past.

> I've done a lot of
> programming in C,C++ mainly because I wanted to write graphical
> simulation programs and the acces to the libraries (X11, Xview,
> Sunview etc) was up to date when using C and C++. Meanwhile C++ 
> is becoming way to big for me. 

Ditto.  A PL is just a tool, not a lifestyle.

> Most of my programs are in C++ and are
> based on OOP and X11R4-Xview. How easy is it to convert things. 

Until someone (maybe GNU?) completes a decent PD (public domain) M3 
compiler, I'd say it's impossible.  DEC's PD M3 is much too large to 
be taken seriously.

I know that several of the design decisions Wirth made with M2 were
intended to support C-like efficiency, especially for systems programming.
It's highly probable that even a barely-adequate M3 compiler would
sport an operational C foreign-function interface.

> Do Modula-3 and/or Oberon support operator-overloading etcetera. How good
> is there graphical capability. 

I suspect few graphics libraries will be built expressly for M3 compilers.
It's much easier to have the user call directly to C libraries or build 
their own M3 wrappers around external C functions.

> I read about Trestle for M3 but is it
> worth it? What are the graphical interfaces for Oberon?? 

???
-- 

| Randy Crawford        crawford@mitre.org        The MITRE Corporation
|                                                 7525 Colshire Dr., MS Z421
| N=1 -> P=NP           703 883-7940              McLean, VA  22102


======================================================================= 47 ===
Date:    19 Oct 1993 13:19:15 GMT
From:    pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
Subject: Re: M3 vs Oberon capabilities

Puh, it's been quite a time since I saw such an incompetent posting in
this group. You have obviously never worked with either of the two
languages or even read the FAQs. Why are you posting then?

crawford@boole.mitre.org (Randy Crawford) writes:

>Oberon is a version of Modula2 without several of the data types and
>operators that Wirth thought were largely uneeded by most programmers 
>(and sometimes hard to implement).  Oberon is a subset of Modula2, 
>and if M2 is not an OOPL (which it's not) then neither is Oberon.
>Modula3 adds single inheritance and simple polymorphism.  I believe
>that operator overloading is not supported (which is fine by me).
>

Wrong. Oberon features extendible records and thus polymorphism.
What Oberon misses is a predefined notion of methods, which one
has to implement with procedure variables.
Also included in Oberon are garbage collection and multidimensional
open arrays. Oberon is definitely not a Modula-2 subset.
Dropped from Modula-2 are variant records, enumeration types, FOR
loops, and subranges.

>I've heard tell that some sort of extended variant of Oberon exists
>which *is* an OOPL, but good luck to you finding a compiler.  Better
>to stick with M3 if you feel Modulish.  IMHO, Oberon's heyday is past.
>

You probably refer to Oberon-2, a successor to Object Oberon. This is
a superset of Oberon with some features reintroduced which were dropped
in Oberon, like the FOR statement. Also introduced are type-bound
procedures, an equivalent to methods.
Oberon-2 is freely available from neptune.inf.ethz.ch.

>Until someone (maybe GNU?) completes a decent PD (public domain) M3 
>compiler, I'd say it's impossible.  DEC's PD M3 is much too large to 
>be taken seriously.
>

The basic Modula-3 compiler is about 3MB. This is quite the same size
as that of gcc. Of course, there is a great bunch of additional
libraries, which can be installed optionally.

>I suspect few graphics libraries will be built expressly for M3 compilers.
>It's much easier to have the user call directly to C libraries or build 
>their own M3 wrappers around external C functions.
>

There is an extensive graphic library for Modula-3. On the lowest level
there is a simple interface to X11R4. Upon that, there is a basic graphic
layer called Trestle, which can be compared to the Athena Widget Set.
On the next level, we have VBTKit, a tool collection for Trestle.
And for high level graphics, there is FormsVBT, comparable to
interviews. I like it, but everbody should evaluate that for himself.
I can't say anything about the effort to rewrite existing applications
in Modula-3/FormsVBT, since I don't know much about interviews. But
it's definitely worth a look. You can find the complete documentation
for VBTKit and FormsVBT as well as the Modula-3 compiler on
gatekeeper.dec.com.

If you want to get a quick overview over Oberon-2 and Modula-3, you
might want to look at a paper called "A Comparison of Object-Oriented
Programming in Four Modern Languages" by Robert Henderson and Benjamin
Zorn from UCB. It's available from their ftp server (ftp.cs.colorado.edu).
For more details, take a look at
Oberon(-2): Oberon-2 language report, same ftp server as above
            Niklaus Wirth: From Modula to Oberon, Software - Practice
              and Experience, 18(7), July 1988
            Hanspeter Mossenbock and Niklaus Wirth: The programming
              language Oberon-2, Structured Programming, 12, 1991
Modula-3: Modula-3 language report (revised), DEC TR 52, 1989
            (ftp'able postscript is around, but I've forgotten where)
          Sam Harbison: Modula-3, Prentice Hall, 1992
          Greg Nelson (ed.): Systems Programming with Modula-3, Prentice
            Hall, 1991
          
Peter
---
Peter Klein                        E-Mail: pk@i3.informatik.rwth-aachen.de
Lehrstuhl fuer Informatik III      Tel.: +49/241/80-21311
Ahornstrasse 55                    Fax.: +49/241/80-21329
RWTH Aachen
52074 Aachen
Germany




======================================================================= 48 ===
Date:    Tue, 19 Oct 1993 16:26:50 GMT
From:    whitney@oberon.Meakins.McGill.CA ()
Subject: Re: M3 in a C/C++ world

Bob Strzelinski (strzelin@sscdaq.phy.bnl.gov) wrote:
: In article <CEuA46.DHo@bcstec.ca.boeing.com>, george@bcstec.ca.boeing.com (Ha
rry G. George) writes:

: |> We really need a general C-to-Modula3 translator, which converts .h files
: |> to .i3 files.  It needs to understand the preprocessor commands, e.g.
: |>     #include "Abc.h"     --> IMPORT Abc;
: |>     #define abc          --> CONST abc = TRUE;
: |>     #define def 2.345    --> CONST def = 2.345;
: |>     #define ghi "Hello"  --> [in .i3] VAR ghi := CharStar;
: |>                              [in .m3] ghi := TtoS("Hello");
: |>     #define jkl (x) (x*3)--> <*INLINE*>
: |>                              PROCEDURE jkl(x:INTEGER):INTEGER =
: |>                              BEGIN
: |>                                RETURN x*3;
: |> 			     END jkl;
: |> 
: |> Of course, there is likely to be some hand-tweaking, but a good translator
: |> would keep us in the game as more and more C libraries arrive in the
: |> market.

A header file translator might be useful for code that is no going
to be rewritten. As for sources themselves, it is often more cost 
effective  to rewrite the code from scratch than use C sources. 

: This is the most significant roadblock to using m3 in my environment.  I do
: a lot of GUI work and everyone wants Motif-compliance.  Even if they're not
: sure what it means.  An simple Motif interface library would be sufficient
: (if I had the time...) but what would really be nice is something like the
: public domain motif++ library which encapsulates all the Motif widgets as
: C++ classes.  I've found this approach very useful (it's even easier to 
: learn Motif this way) and it seems a natural approach for an m3 toolkit also.

Alternatively, one could design window decorations to make Trestle
look like Motif. This would keep end-users happy.

There is little advantage in using Motif from a programmers 
point of view. The system is relatively hard to work with.




Whitney


======================================================================= 49 ===
Date:    Tue, 19 Oct 93 16:05:13 GMT
From:    buschman@slsvaat.sel.de (Andreas Buschmann US/END 60/1/25 Tel.71409)
Subject: Why structural equivalence?

My main reasons to have structural equivalence instead of name
equivalence are

 a) Names

    If you have structural equivalence you usually have one name for a
    record. for example 

	TYPE Triple = RECORD x, y, z : LONGREAL; END;

    You don't create extra names for pointers to this type, but write
    something like

	VAR p : REF Triple;
	VAR pp : REF REF Triple;

    If instead you have name equivalence, you will have to give
    explicit names to all these types saying:

	TYPE Triple = RECORD x, y, z : LONGREAL;
	TYPE RefTriple = REF Triple;
	TYPE RefRefTriple = REF RefTriple;
	...

    If you are going to share code, all these definitions have to go
    into the Interface / Definition Module shared by everyone. And if
    you later find out you need one more REF, you better have it in
    your Interface / Definition Module. If not, you either add it
    there, so everything has to recompile (which is a pain if you are
    developing distributed), or you add it to one of your private
    files, whichs gives you problems if someone else needs this type
    also. 


 b) Access

    Say someone wrote a type like

	TYPE Quadruple = REF RECORD a, b, c, d : REAL; END;

    and you want to store this thing in a list, or a bigger structure.
    What you want is a type

	<your favourite type name> = RECORD a, b, c, d : REAL; END;

    so you can add it to your own structure

	TYPE QList = RECORD
		REF QList next;
		<your favourite type name> q;
	END

    This really isn't possible with name equivalence. Once someone
    forgot to name some intermediate type, you are lost.

    Don't tell me, it doesn't happen, I have seen it more than once.
    Even in Interfaces distributed with professional Moula2 Compilers
    / Libraries. And you can't edit them, cause you don't have the
    source to the libraries.


Of cause, I am biased. I leaned programming using Algol68 (at
university). Three years later I teached programming to other students
using Modula2.

				Tschuess
					Andreas
-- 
#include <stddisclaimer.h>

 /|)	Andreas Buschmann
/-|)	SEL Stuttgart US/END

	buschman@us-es.sel.de


======================================================================= 50 ===
Date:    Tue, 19 Oct 1993 00:31:01 GMT
From:    ihandler@metatron.win.net (Ivan Handler)
Subject: Re: Doctor Dobbs Article

 
In article <750947873snz@rtal.demon.co.uk>, Ian Marshall (ian@rtal.demon.co.uk)
 writes:
>In article <1993Oct18.055912.5789@seagoon.newcastle.edu.au> peter@tesla.newcas
tle.edu.au writes:
>
>>That's a step backwards, in my opinion.  The automatic generators
>>strip out the comments.  What good is a definition module
>>without comments?
>
>This is completely implementation dependant. For example, our Extacy
>Oberon-2 implementation (latest release) will now keep selected comments
>in the pseudo-definition module. You also have a certain degree of control
>of ordering. For example, in other browsers I have seen (including earlier
>versions of our own) the order of the pseudo-def was alphabetic (mostly
>because the symbol file is arranged this way). I always found this 
>irritating as I grouped definitions according to relation of use.
>
Tell us more about Extacy, which platforms does it run on?

>>On the other hand, Oberon does teach us one valuable lesson:
>>with type extensibility, you can get the advantages of
>>OOP without actually having to go down the OOP path.
>
>I don't see what you mean. Oberon (or at least Oberon-2) is definitely
>object-oriented. Only the 'standard' jargon has been removed. Replace
>'type extension' with 'inheritance' (as it is the same thing) and you
>have 'object-oriented' jargon and functionality.
>
I believe that part of the problem with OOP & Modula is that Modula
is a pre-OOP language and a very good one at that.  I tend to use
data-abstraction via functional parameters in lieu of
inheritance.  I think this is a perfectly valid way of proceeding
that is not in use because of the OOP's popularity (fad??).  If
you really want to go OOP then Oberon or Eiffel or Ada 9X are
languages that were designed around OOP concepts.  None of them
are as loose or messy as C++.

For myself I find Modula to be very powerful and useful in many
circumstances and I continue to use it as is. 

--
Ivan Handler                            Internet: ihandler@metatron.win.net
2513 N. Central Park                    CI$: 70705,232
Chicago, IL 60647                       Fax: (312) 342-4518


======================================================================= 51 ===
Date:    Tue, 19 Oct 1993 12:28:23 +0000
From:    ian@rtal.demon.co.uk (Ian Marshall)
Subject: Re: M3 vs Oberon capabilities 

In article <29v26f$8k1@newsflash.mitre.org> crawford@boole.mitre.org writes:

>I've heard tell that some sort of extended variant of Oberon exists
>which *is* an OOPL, but good luck to you finding a compiler.  

'Some sort of extended variant of Oberon' is Oberon-2, has been around
for some time now, and has many implementations. We supply for just about
every platform.

Another point to note is that in news and the like the name Oberon is
often used to represent the language Oberon-2 (in the same way as many
people call Modula-2 Modula, on the basis that the real Modula is no
longer really represented and every body knows what you're talking about
anyway). The problem is that, as mentioned in an earlier posting, Oberon 
itself is actually an OS and environment, not just a language - and there 
is no specific 'Oberon-2' environment. There are of course many 
implementations of the Oberon and Oberon-2 languages which are freestanding.


>                                                              Better
>to stick with M3 if you feel Modulish.  IMHO, Oberon's heyday is past.


Which considering your comment about 'some sort of extended variant of
Oberon' is not a particularly informed opinion. Oberons 'heyday' hasn't 
come yet. A de-facto uninformal definition from a conference in September is 
about to be released (the views of about 40 compiler manufacturers, 
including ETH, are represented within). Oberon-2 is just catching on and
is getting an accelerating following (see comp.lang.oberon if you don't
believe me).

It appears to me that you have taken the unfortunate path of the 
C and C++ fanatics who believe that they are using the one and only
correct language in the world, and can thereby pass judgement on languages
which they clearly know nothing about.

-- 
-------------------------------------------------------------------------
Ian Marshall,
Real Time Associates Ltd,          Tel        : (+44)(0)81 656 7333/4/5
Canning House, 59 Canning Road,    Fax        : (+44)(0)81 655 0401
Croydon,Surrey,CR0 6QF             Email      : ian@rtal.demon.co.uk
UK                                 Compuserve : 71333,2456      
-------------------------------------------------------------------------


======================================================================= 52 ===
Date:    Tue, 19 Oct 1993 14:47:44 GMT
From:    strzelin@sscdaq.phy.bnl.gov (Bob Strzelinski)
Subject: Re: M3 in a C/C++ world

In article <CEuA46.DHo@bcstec.ca.boeing.com>, george@bcstec.ca.boeing.com (Harr
y G. George) writes:
|> Thank you to those who responded to my query re running
|> trestle on SUN.  The fixes worked. Thank you to those who designed 
|> and built trestle, vbt, et al. Looks like a clean, robust approach.
|> 
|> OTOH, we live in a C/C++/Motif world.  I might be able to
|> sell folks on Modula3 as a replacement for C++, or as a code generator
|> for C.  But I can't ignore the growing reuse libraries of Motif-based
|> widgets.  (Betamax may have been better than VHS, but VHS won.)  Therefore:
|> 
|> Does anyone have a set of Motif .i3 files (e.g., following the pattern
|> of the X and Xt interfaces in the M3 release)?  If not , is anyone 
|> interested in helping prepare a PD version of same?  
|> 
|> We really need a general C-to-Modula3 translator, which converts .h files
|> to .i3 files.  It needs to understand the preprocessor commands, e.g.
|>     #include "Abc.h"     --> IMPORT Abc;
|>     #define abc          --> CONST abc = TRUE;
|>     #define def 2.345    --> CONST def = 2.345;
|>     #define ghi "Hello"  --> [in .i3] VAR ghi := CharStar;
|>                              [in .m3] ghi := TtoS("Hello");
|>     #define jkl (x) (x*3)--> <*INLINE*>
|>                              PROCEDURE jkl(x:INTEGER):INTEGER =
|>                              BEGIN
|>                                RETURN x*3;
|> 			     END jkl;
|> 
|> Of course, there is likely to be some hand-tweaking, but a good translator
|> would keep us in the game as more and more C libraries arrive in the
|> market.
|> 
|> I built a Perl script which does part of the job.  I've been thinking of 
|> trying to use TXL or PCCTS to do a more robust job.  Sure would like
|> to hear that someone else has already solved it.
|> 
|> [Reply to address below]
|> ---------------------------------------------------------
|> Disclaimer:  Any opinions expressed herein are my own and
|>              not those of The Boeing Company.
|> Contact:     Harry George, BCAG Automated Software Analysis  
|> Phone:       (206) 237-6915  Org: 6-6541  M-S: 6A-UA
|> E-mail:      george@garden.ca.boeing.com
|> IP address:  137.137.45.51                     
|> 

This is the most significant roadblock to using m3 in my environment.  I do
a lot of GUI work and everyone wants Motif-compliance.  Even if they're not
sure what it means.  An simple Motif interface library would be sufficient
(if I had the time...) but what would really be nice is something like the
public domain motif++ library which encapsulates all the Motif widgets as
C++ classes.  I've found this approach very useful (it's even easier to 
learn Motif this way) and it seems a natural approach for an m3 toolkit also.


///////////////////////////////////////////////////////////////////////////////
// Robert J Strzelinski                 // Brookhaven National Laboratory    //
// strzelin@sscdaq.phy.bnl.gov          // Upton, NY 11973-5000              //
///////////////////////////////////////////////////////////////////////////////


======================================================================= 53 ===
Date:    19 Oct 93 19:56:15 GMT
From:    blaak@csri.toronto.edu (Raymond Blaak)
Subject: Re: Why structural equivalence?

buschman@slsvaat.sel.de (Andreas Buschmann US/END 60/1/25 Tel.71409) writes:


>    If you are going to share code, all these definitions have to go
>    into the Interface / Definition Module shared by everyone. And if
>    you later find out you need one more REF, you better have it in
>    your Interface / Definition Module. If not, you either add it
>    there, so everything has to recompile (which is a pain if you are
>    developing distributed), or you add it to one of your private
>    files, whichs gives you problems if someone else needs this type
>    also.

Presumably if shared code needs one more REF, it also needs operators using 
that one more REF, and so the interface module needs to be changed anyway.

If the use of the shared code doesn't require the extra REF, then having local
type definitions of the extra REF won't impact on the use of the shared code.
If someone else needs this type they should be able to declare their own local
reference type too.

>    Say someone wrote a type like

>	TYPE Quadruple = REF RECORD a, b, c, d : REAL; END;

>    and you want to store this thing in a list, or a bigger structure.
>    What you want is a type

>	<your favourite type name> = RECORD a, b, c, d : REAL; END;

>    so you can add it to your own structure

>	TYPE QList = RECORD
>		REF QList next;
>		<your favourite type name> q;
>	END

>    This really isn't possible with name equivalence. Once someone
>    forgot to name some intermediate type, you are lost.

In languages with strict name equivalence, it shouldn't be possible to write
unnamed intermediate types. Thus there would always be a named record type for
one to use.

Cheers,
Ray
blaak@csri.toronto.edu


======================================================================= 54 ===
Date:    Tue, 19 Oct 93 07:44:10 CEST
From:    g_dotzel@obula.nbg.sub.org (Guenter Dotzel)
Subject: Re: Doctor Dobbs Article 

> This is completely implementation dependant. For example, our Extacy
> Oberon-2 implementation (latest release) will now keep selected comments

Ian, it's not your Oberon-2 implementation!
Extacy may be a trademark of RTA, but RTA did not write the compiler.

Guenter


======================================================================= 55 ===
Date:    20 Oct 1993 09:52:24 GMT
From:    laszlo@post.ifi.uni-klu.ac.at (Laszlo BOESZOERMENYI)
Subject: Re: M3 vs Oberon capabilities

You might read the paper

A Comparison of Modula-3 and Oberon-2
in Structured Programming (1993) 14: 15-22
by L. Boszormenyi

The comparison is not exhaustive, concentrates on
the most essentila features.

Best regards

Laszlo Boszormenyi

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

Prof. Laszlo Boeszoermenyi
Institut fuer Informatik

Universitaet Klagenfurt
Universitaetsstr. 65-67
A-9022 Klagenfurt / Austria

e-mail:
laszlo@ifi.uni-klu.ac.at
Tel.: 
00-43-463-2700-509 
00-43-463-2700-506 (secr.)
Fax.:
00-43-463-2700-505 


======================================================================= 56 ===
Date:    Mon, 18 Oct 1993 14:30:12 MST
From:    "D. C. Sessions" <dcs@witsend.stat.com>
Subject: Going in circles

In <1993Oct18.055912.5789@seagoon.newcastle.edu.au>, peter@laplace.newcastle.ed
u.au (Peter Moylan)  wrote:
# 
# whitney@oberon.Meakins.McGill.CA wrote:
# >Peter Moylan (peter@laplace.newcastle.edu.au) wrote:

# >Note: This would require that symbol files be generated from a mixture
# >of definition and implementation modules rather than just definition
# >modules as is the case for Modula-2.  There is not enough
# >information in the definiton modules to determine the offsets 
# >of fields, record sizes, etc as required by OOP.
# 
# Oh, if only the standard would allow that!  Not so much because
# I want OOP, but because it would at last remove the stupid
# rule about opaque types having to be pointers.
# 
# There's a catch, though: to make this work, you might have to
# ban circular dependencies among modules.  (Not just circularities
# in the definition modules - these are already banned - but
# circularities involving the implementation modules.)  That
# wouldn't bother me, since I believe that a circularity in
# imports is a priori evidence of a design error, but apparently
# it would bother some people.

  This seems to be a good launch-point for a thread with some
  actual content.  I seem to recall an example from some while
  back of modules which pretty well HAD to be circular, but now
  forget the details.

  Let's debate the point, "Resolved: circular dependency between
  implementatuion modules always reflects bad design."

--- D. C. Sessions                            Speaking for myself ---
--- Note new network address:                dcs@witsend.stat.com ---
--- Author (and everything else!) of TMail  (DOS mail/news shell) ---


======================================================================= 57 ===
Date:    20 Oct 1993 13:51:30 GMT
From:    pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
Subject: Re: Why structural equivalence?


buschman@slsvaat.sel.de (Andreas Buschmann US/END 60/1/25 Tel.71409) writes:

>With the REF operator / function I mean one keeping the base type.
>
>	F       (lvalue : TYPE T) -> rvalue : TYPE TRACED REF T
>	 traced
>
>	F       (lvalue : TYPE T) -> rvalue : TYPE UNTRACED REF T
>	 untraced

Hmm, if I'm not missing something, there are three possibilities:

1. lvalue is on the stack (variable) and should stay there. Then, rvalue
   cannot be some REF, since REF points into the heap. The only chance
   to reference lvalue would be to use the ADR operator, which returns
   type ADDRESS.

2. lvalue is on the stack and should be put on the heap. Then,
     rvalue := NEW((UNTRACED) REF T); rvalue^ := lvalue;
   should do.

3. lvalue is on the heap. Then, you already have a pointer to it.

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




======================================================================= 58 ===
Date:    Wed, 20 Oct 1993 14:55:37 GMT
From:    dagenais@gutrune.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: Modula 3 for Macintosh


   Is there a Modula 3 compiler for the Macintosh series?

Currently none but the upcoming 3.0 release, in alpha test currently,
should be easier to port.
--
---------------------------------------------------------------------

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

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


======================================================================= 59 ===
Date:    Wed, 20 Oct 93 12:48:27 GMT
From:    buschman@slsvaat.sel.de (Andreas Buschmann US/END 60/1/25 Tel.71409)
Subject: Re: Why structural equivalence?

blaak@csri.toronto.edu (Raymond Blaak)
: me
: 
: >    If you are going to share code, all these definitions have to go
: >    into the Interface / Definition Module shared by everyone. And if
: >    you later find out you need one more REF, you better have it in
: >    your Interface / Definition Module. If not, you either add it
: >    there, so everything has to recompile (which is a pain if you are
: >    developing distributed), or you add it to one of your private
: >    files, whichs gives you problems if someone else needs this type
: >    also.
 
: Presumably if shared code needs one more REF, it also needs operators
: using that one more REF, and so the interface module needs to be
: changed anyway.
 
: If the use of the shared code doesn't require the extra REF, then
: having local type definitions of the extra REF won't impact on the use
: of the shared code.  If someone else needs this type they should be
: able to declare their own local reference type too.

I usually don't require extra operators or functions, if I am just
shuffeling stuff around. What I need is the address operator in C,
ADDRESS in Modula2 (which doesn't keep the base type), a missing REF
operator or function in Modula3, and just leaving the dereferenciation
out in Algol68.

With the REF operator / function I mean one keeping the base type.

	F       (lvalue : TYPE T) -> rvalue : TYPE TRACED REF T
	 traced

	F       (lvalue : TYPE T) -> rvalue : TYPE UNTRACED REF T
	 untraced

			Tschuess
				Andreas

-- 
#include <stddisclaimer.h>

 /|)	Andreas Buschmann
/-|)	SEL Stuttgart US/END

	buschman@us-es.sel.de


======================================================================= 60 ===
Date:    21 Oct 93 05:58:57 GMT
From:    khaw@parcplace.com
Subject: Re: Doctor Dobbs Article

In <59@metatron.win.net> ihandler@metatron.win.net (Ivan Handler) writes:
...
->inheritance.  I think this is a perfectly valid way of proceeding
->that is not in use because of the OOP's popularity (fad??).  If
						      ^^^
about as much as Unix is a fad, since they are about the same
vintage (roughly).

->you really want to go OOP then Oberon or Eiffel or Ada 9X are
->languages that were designed around OOP concepts.  None of them

and Smalltalk is chopped liver?

--
Michael Khaw	khaw@parcplace.com (or khaw%parcplace.com@netcom.com)
ParcPlace Systems, Sunnyvale, CA	PRODUCT INFO: info@parcplace.com


======================================================================= 61 ===
Date:    Thu, 21 Oct 93 08:41:50 GMT
From:    buschman@slsvaat.sel.de (Andreas Buschmann US/END 60/1/25 Tel.71409)
Subject: Re: Why structural equivalence?

pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
: me
: >With the REF operator / function I mean one keeping the base type.
: >
: >	F       (lvalue : TYPE T) -> rvalue : TYPE TRACED REF T
: >	 traced
: >
: >	F       (lvalue : TYPE T) -> rvalue : TYPE UNTRACED REF T
: >	 untraced
: 
: Hmm, if I'm not missing something, there are three possibilities:
: 
: 1. lvalue is on the stack (variable) and should stay there. Then, rvalue
:    cannot be some REF, since REF points into the heap. The only chance
:    to reference lvalue would be to use the ADR operator, which returns
:    type ADDRESS.

You assume here a traced REF like in the current Implementation of
Modula3, which usually points only to the heap. The more generic REF
(like in Algol68) may point anywhere.

This can be handy sometimes. There are some nice algorithms for linked
lists, which require a pointer to the root pointer of the linked list,
and then step through, pointing to the next fields.

You can of cause run into problems with the lifetime of memory
objects.

: 3. lvalue is on the heap. Then, you already have a pointer to it.

No, I have not necessarily. Lets assume

	TYPE REC = RECORD x, y, z : INT; END;
	VAR rec : REF REC := NEW (REC);
	VAR pin : REF INT := F (rec^.z);

Now pin points to the heap, but into the middle of a memory object, not
to the beginning of it. 

You could name this No.4.

4. lvalue is on the heap, but not allocated by new. It is part of
   something allocated by new.

5. lvalue is in static memory; it either is a (modul) global variable
   or part of a global variable. (No problems with lifetime here.)

But this is really getting away from structural equivalence into the
memory concept of languages and memory allocation.


				Tschuess
					Andreas
-- 
#include <stddisclaimer.h>

 /|)	Andreas Buschmann
/-|)	SEL Stuttgart US/END

	buschman@us-es.sel.de



======================================================================= 62 ===
Date:    21 Oct 1993 12:02:02 GMT
From:    pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
Subject: Address Operators (was: Why structural equivalence?)


buschman@slsvaat.sel.de (Andreas Buschmann US/END 60/1/25 Tel.71409) writes:

>pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
>: me
>: >With the REF operator / function I mean one keeping the base type.
>: >
>: >	F       (lvalue : TYPE T) -> rvalue : TYPE TRACED REF T
>: >	 traced
>: >
>: >	F       (lvalue : TYPE T) -> rvalue : TYPE UNTRACED REF T
>: >	 untraced
>: 
>: Hmm, if I'm not missing something, there are three possibilities:
>: 
>: 1. lvalue is on the stack (variable) and should stay there. Then, rvalue
>:    cannot be some REF, since REF points into the heap. The only chance
>:    to reference lvalue would be to use the ADR operator, which returns
>:    type ADDRESS.
>
>You assume here a traced REF like in the current Implementation of
>Modula3, which usually points only to the heap. The more generic REF
>(like in Algol68) may point anywhere.
>

Yes, but REF'ed objects being on the heap is not just a SRC m3
implementation detail, it's necessary for the semantics of the
language.
Let's see what NEW should do: obviously, it cannot allocate something
on the stack. The stack's size cannot be expanded arbitrarily at run
time. And what should DISPOSE do on the stack? What should the
garbage collector do on the stack? I would say he couldn't do anything,
since, for stack objects, the property of being garbage or in use has
nothing to do with the existence of any pointers to it.

>This can be handy sometimes. There are some nice algorithms for linked
>lists, which require a pointer to the root pointer of the linked list,
>and then step through, pointing to the next fields.
>

Why do you require a *pointer* to the root pointer? If I walk through a
linked list, I initialize the current pointer to the root pointer and
advance through the list using the "next" links.

>You can of cause run into problems with the lifetime of memory
>objects.
>

Indeed, that's the problem. One important feature which distinguishes
stack from heap objects is that stack object lifetimes are determined
by their scope, whereas heap object lifetimes are controlled by the
dynamic execution path of the program. I don't see a reason to give up
this concept.

>: 3. lvalue is on the heap. Then, you already have a pointer to it.
>
>No, I have not necessarily. Lets assume
>
>	TYPE REC = RECORD x, y, z : INT; END;
>	VAR rec : REF REC := NEW (REC);
>	VAR pin : REF INT := F (rec^.z);
>
>Now pin points to the heap, but into the middle of a memory object, not
>to the beginning of it. 
>
>You could name this No.4.
>
>4. lvalue is on the heap, but not allocated by new. It is part of
>   something allocated by new.
>

Two points here:
 - Same thing as above: What if I dispose something right out of the
   middle of another object?
 - If it is *intended* to have a pointer to a component of another
   object, then why not write exactly this? For your example:
     TYPE REC = RECORD x, y, z := NEW(REF INT); END;
     VAR rec := NEW(REF REC);
     VAR pin := rec.z;

>5. lvalue is in static memory; it either is a (modul) global variable
>   or part of a global variable. (No problems with lifetime here.)
>

Same as above: if you want a pointer, why not use one?

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




======================================================================= 63 ===
Date:    21 Oct 1993 08:35:39 -0400
From:    thutt@access.digex.net (Taylor Hutt)
Subject: Re: Doctor Dobbs Article

In article <khaw.751183137@parcplace.com>,  <khaw@parcplace.com> wrote:
>In <59@metatron.win.net> ihandler@metatron.win.net (Ivan Handler) writes:
>...
>->inheritance.  I think this is a perfectly valid way of proceeding
>->that is not in use because of the OOP's popularity (fad??).  If
>						      ^^^
>about as much as Unix is a fad, since they are about the same
>vintage (roughly).
>
>->you really want to go OOP then Oberon or Eiffel or Ada 9X are
>->languages that were designed around OOP concepts.  None of them
>
>and Smalltalk is chopped liver?

No, smalltalk is what you do at a party when you see someone of the 
opposite sex that attracts you.

Oh yeah, it was also a computer language of minor importance in the mid 80s.

>Michael Khaw	khaw@parcplace.com (or khaw%parcplace.com@netcom.com)
>ParcPlace Systems, Sunnyvale, CA	PRODUCT INFO: info@parcplace.com
 ^^^^^^^^^^^^^
               Yes, I saw where you were from.  This is a joke, if you are
               humor impaired.

Taylor "Inappropriate Behavior" Hutt
Girls like to dance, guys don't.  Guys like sex.  Guys dance.  -- R. Bessara



======================================================================= 64 ===
Date:    21 Oct 1993 16:45:20 GMT
From:    kalsow@src.dec.com (Bill Kalsow)
Subject: Re: M3 alpha-3.0 on Linux

In article <CF8ynr.L92@oasis.icl.co.uk>, skj@oasis.icl.co.uk (Simon Johnston) w
rites:
> Having ftp-ed the alpha linux compiler from gatekeeper I am having a number o
f
> build problems. 

Yes, it's a known problem.  The alpha-3.0 release was intended for
a few brave pioneers and the curious browsers.  It won't build and
install correctly on most platforms.

The next release should be much better.  I'll announce it when it's released.

> Firstly I had problems getting quake to compile, now fixed, 
> but most important I get an undefined symbol __setjmp, this has meant that 
> I cannot link any of the code. I am using gcc 2.4.5 and libc 4.4.2, could
> someone let me know if this is a known problem ?

The problem is that libm3/runtime/src/LINUX/{RTThread.i3,RTThreadC.c} use
"_setjmp" instead of "__setjmp".  You can get over this problem by
replacing "__setjmp" by "___setjmp" in your .ms and .c files.


 - Bill Kalsow


======================================================================= 65 ===
Date:    Thu, 21 Oct 1993 12:28:39 GMT
From:    skj@oasis.icl.co.uk (Simon Johnston)
Subject: M3 alpha-3.0 on Linux

Having ftp-ed the alpha linux compiler from gatekeeper I am having a number of
build problems. Firstly I had problems getting quake to compile, now fixed, 
but most important I get an undefined symbol __setjmp, this has meant that 
I cannot link any of the code. I am using gcc 2.4.5 and libc 4.4.2, could
someone let me know if this is a known problem ?


MODULE Sig;
FROM ICL IMPORT StdDisclaimer;

BEGIN
(* ------------------------------------------------------------------------.
|Simon K. Johnston - Development Engineer              |ICL Retail Systems |
|------------------------------------------------------|3/4 Willoughby Road|
|Unix Mail : S.K.Johnston.bra0801@oasis.icl.co.uk      |Bracknell, Berks   |
|Telephone : +44 (0)344 476320   Fax: +44 (0)344 476084|United Kingdom     |
|Internal  : 7621 6320    OP Mail: S.K.Johnston@BRA0801|RG12 8TJ           |
`------------------------------------------------------------------------ *)
END Sig.


======================================================================= 66 ===
Date:    21 Oct 1993 15:42:39 GMT
From:    heinze@i41s5.ira.uka.de (Ernst A. Heinz)
Subject: Modula-2* Environment paper (updated version) available by anonymous f
tp

For all interested folks we have now made the final version of our
MPPM'93 paper publicly available by anonymous ftp. The title of the
paper reads as follows:

"The Modula-2* Environment for Parallel Programming"
(by S.U. Haenssgen, E.A. Heinz, P. Lukowicz, M. Philippsen, and W.F. Tichy).
 
To retrieve PostScript or compressed Postscript versions of the paper
please connect to i41s10.ira.uka.de [129.13.13.110] by anonymous ftp.
There, the directory pub/m2s contains the corresponding files named
mppm93.ps and mppm93.ps.Z.

-rw-r-----   1 ftp      ftp        557329 Oct 21 15:27 mppm93.ps
-rw-r-----   1 ftp      ftp        135382 Oct 21 15:27 mppm93.ps.Z

Don't forget to use binary mode when retrieving the compressed
PostScript versions! Please send us a short email containing your full
name and address plus affiliation if you retrieve any of the above.

For your information we include the abstract of our MPPM'93 paper below.
 
-------------------------------------------------------------------------------
-

THE MODULA-2* ENVIRONMENT FOR PARALLEL PROGRAMMING

This paper presents a portable parallel programming environment for Modula-2*,
an explicitly parallel machine-independent extension of Modula-2. Modula-2*
offers synchronous and asynchronous parallelism, a global single address space,
and automatic data and process distribution. The Modula-2* system consists of a
compiler, a debugger, a cross-architecture make, graphical X Windows control
panel, runtime systems for different machines, and sets of scalable parallel
libraries.  The existing implementation targets the MasPar MP series of massive
ly
parallel processors (SIMD), the KSR-1 parallel computer (MIMD), heterogeneous
LANs of workstations (MIMD), and single workstations (SISD).

The paper describes the important components of the Modula-2* environment and
discusses selected implementation issues.  We focus on how we achieve a high
degree of portability for our system, while at the same time ensuring efficienc
y.

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

In case of any questions or problems, please don't hesitate to contact us
directly.
 
Cheers.

=Ernst=
 
+--------------------------------------------------------+-------------------+
| Ernst A. Heinz              (email: heinze@ira.uka.de) |                   |
| Institut fuer Programmstrukturen und Datenorganisation | Make it as simple |
| Fakultaet fuer Informatik, Universitaet Karlsruhe      | as possible, but  |
| Postfach 6980, D-76128 Karlsruhe, F.R. Germany         | not simpler.      |
| (Voice: ++49/(0)721/6084386, FAX: ++49/(0)721/694092)  |                   |
+--------------------------------------------------------+-------------------+


======================================================================= 67 ===
Date:    21 Oct 1993 12:21:11 GMT
From:    laverman@cs.rug.nl (Bert Laverman)
Subject: Re: Why structural equivalence?

Andreas Buschmann writes:
> Peter Klein:
> : 1. ...
> You assume here a traced REF like in the current Implementation of
> Modula3, which usually points only to the heap. The more generic REF
> (like in Algol68) may point anywhere.
This is not a 'more generic ref', it is the UNTRACED REF.

> This can be handy sometimes. There are some nice algorithms for linked
> lists, which require a pointer to the root pointer of the linked list,
> and then step through, pointing to the next fields.
The usual reason for wanting to do that is that:
  - you don't have VAR parameters, or (more likely)
  - you don't have something like objects, and want to simulate
    a supertype which is known to have a 'next' field as its
    first member.

> You can of cause run into problems with the lifetime of memory
> objects.
  Which is why taking the ADR() of something may only be done in UNSAFE
MODULEs in Modula-3. Same for LOOPHOLEing and pointer arithmatic.

> : 3. ...
> No, I have not necessarily. Lets assume
> 
> 	TYPE REC = RECORD x, y, z : INT; END;
> 	VAR rec : REF REC := NEW (REC);
> 	VAR pin : REF INT := F (rec^.z);
> Now pin points to the heap, but into the middle of a memory object, not
> to the beginning of it. 

So:
  TYPE REC = RECORD x, y, z : INTEGER; END;
  VAR rec : UNTRACED REF REC;
  VAR pin : UNTRACED REF INTEGER;
  ...
  rec := NEW(UNTRACED REF REC);
  pin := ADR(rec^.z);

This is valid (though UNSAFE) Modula-3. See '2.7 Unsafe operations',
page 59 in SPwM3.

> You could name this No.4.
> 4. lvalue is on the heap, but not allocated by new. It is part of
>    something allocated by new.
> 5. lvalue is in static memory; it either is a (modul) global variable
>    or part of a global variable. (No problems with lifetime here.)
These are both coverd by the ADR() function.

Greetings, Bert
-- 
  ------------------------------------------------------------------
  Bert Laverman,   Dept. of Computing Science,  Groningen University
  Email: laverman@cs.rug.nl			Phone: +31-50-633948
  Home:  bert@rakis.iaf.nl			Fax:   +31-50-633800


======================================================================= 68 ===
Date:    Thu, 21 Oct 1993 18:07:43 +0000
From:    catalogue@rtal.demon.co.uk (Electronic Sales Dept)
Subject: Catalogue Available

------------------------------------------------------------------------
 Modula-2, Oberon-2, Fortran-90, C++ catalogues available by Email
------------------------------------------------------------------------
                      Autumn 1993 RTA Catalogue

Catalogues are in ascii text form, of conveniently email-able size, 
consisting of brief product descriptions, prices, details of how to
obtain more full product descriptions and email order information.

Send your request to:
    
    catalogue@rtal.demon.co.uk

Stating clearly :
      
      Programming language you are interested in
         - M2, O2, F90, C++
      Platforms you are interested in
         - DOS, OS/2, Unix (all), Windows/NT, VMS, 
           Macintosh, Amiga, Archimedes, Cross/Embedded
      Your Email address
      State whether academic or commercial organisation
      (optional) Your actual address,telephone, fax

Catalogues will be distributed from Monday 25th October 1993
------------------------------------------------------------------------


======================================================================= 69 ===
Date:    22 Oct 93 11:29:14
From:    hosking@cs.umass.edu (Tony Hosking)
Subject: Alpha 3.0 installation

Has anyone had any success in building and installing the SRC Modula-3 Alpha
3.0 release on a DECstation?  Everything built OK (with a few minor tweaks),
but the driver seems to be misconfigured---"m3 -\?" produces the following
output:

pass 0       := *UNDEFINED*pass 1       := *UNDEFINED*pass 2       :=
*UNDEFINED*pass 2 base  := pass 3       := *UNDEFINED*pass 4       := *UNDEFINE
D*pass 6       := def path     := lib path     := include      := server limit 
:= 0 megabytesmake mode    := FALSEbootstrap    := FALSEstd libs     := TRUE ke
ep files   := FALSEcoverage     := FALSE resolve libs := FALSE-O           => -
g           =>

which certainly doesn't look right.  I checked the template file I am using
and it certainly appears to have the right configuration information for the
driver.  I'd really appreciate any tips folks might have.
--
		Tony Hosking
Papernet:	Dept. of Computer Science
		University of Massachusetts			 _--_|\
		Amherst, MA 01003				/      \
Voicenet:	(413) 545-0256					\_.--._/    )
Faxnet:		(413) 545-1249					      v    /
Internet:	hosking@cs.umass.edu


======================================================================= 70 ===
Date:    23 Oct 1993 11:11:11 GMT
From:    heinze@i41s5.ira.uka.de (Ernst A. Heinz)
Subject: Availability of Modula-2* Programming Environment

After putting the updated version of our MPPM'93 paper on ftp I received
several mails asking for the availability of our Modula-2* Programming
Environment. Because this might be of public interest I now post an answer
to the net.

"The Modula-2* people (email: msc@ira.uka.de) at the University of Karlsruhe,
F.R.G., are currently preparing a new version of their Modula-2* programming
environment to be publicly released at the end of November. The upcoming
release will consist of binaries for DECStations and SparcStations. Target
architectures include the MasPar MP series, the KSR-1, and several sequential
Unix workstations."

We will announce the availability of the new version on the net as soon as it
is ready for public release. So please stay tuned!

Cheers.

=Ernst=
 
+--------------------------------------------------------+-------------------+
| Ernst A. Heinz              (email: heinze@ira.uka.de) |                   |
| Institut fuer Programmstrukturen und Datenorganisation | Make it as simple |
| Fakultaet fuer Informatik, Universitaet Karlsruhe      | as possible, but  |
| Postfach 6980, D-76128 Karlsruhe, F.R. Germany         | not simpler.      |
| (Voice: ++49/(0)721/6084386, FAX: ++49/(0)721/694092)  |                   |
+--------------------------------------------------------+-------------------+


======================================================================= 71 ===
Date:    Sun, 24 Oct 1993 16:20:07 GMT
From:    pgs1002@cus.cam.ac.uk (Dr P.G. Sjoerdsma)
Subject: getting SRC-reports


Can anyone tell me how to get a SRC report, in this case about Trestle
and FormsVBT. I mailed them at:

src-report@src.dec.com

twice now but no reply.

Thanks in advance.
--
                                 ___
                                (o o) 
-----------------------------ooO-(_)-Ooo-----------------------------
        Paul Sjoerdsma, Godwin Laboratory, Free School Lane,
                     Cambridge CB2 3RS England
       fax:   (44) (0)223-334871, email: pgs1002@cus.cam.ac.uk
---------------------------------------------------------------------





======================================================================= 72 ===
Date:    Sun, 24 Oct 1993 23:12:01 GMT
From:    kirschnt@informatik.uni-muenchen.de (Torsten R. Kirschner)
Subject: Re: getting SRC-reports

pgs1002@cus.cam.ac.uk (Dr P.G. Sjoerdsma) writes:

>Can anyone tell me how to get a SRC report, in this case about Trestle
>and FormsVBT. I mailed them at:
>src-report@src.dec.com
>twice now but no reply.

Another way to retrieve them in electronic form is this ftp server,
gatekeeper.dec.com:/pub/DEC/SRC/research-reports
This directory holds a lot of the DEC SRC reports (and also an index
to them). 

Torsten
-- 
Torsten R. Kirschner          Torsten.R.Kirschner@informatik.tu-muenchen.de


======================================================================= 73 ===
Date:    Thu, 21 Oct 1993 15:12:51 GMT
From:    grp@dmu.ac.uk (Graham Perkins)
Subject: Re: Doctor Dobbs Article

> Message-ID: <29tf69$2qi@darum.uni-mannheim.de>

-Peter Moylan (peter@laplace.newcastle.edu.au) wrote:
-: whitney@oberon.Meakins.McGill.CA wrote:
-: >BTW, Other languages such as Oberon ( a successor to Modula-2 )
-: >have a single source which used to generate *.Sym and *.Obj files. 
-: >Definition modules are also generated. They are not written 
-: >by the programmer. They are not used for documentation but
-: >serve as on-line references for the programmer familiar
-: >with the design of the module. 
-:
-: That's a step backwards, in my opinion.  The automatic generators
-: strip out the comments.  What good is a definition module
-: without comments?
-
-I think the problem here is not that the merge of definition and 
-implementation were a bad thing, but the lack of a sufficiently clever
-documentation tool. What I'd like to see is a convention how to attach
-public comments to declared entities (including the whole module), which
-would then be extracted by the browser. There would probably have to be
-some restrictions on comment formatting, but e.g. choosing between either
-one-line comments or block comments on lines of their own would be ok.
-This way you could also embed some other information for automatic cross
-referencing, like the 'index' entries in Eiffel.

Yup, I think the documentation tool is the key issue here.  The point
is that interface and implementation are two different views of the
same object: a proc/fn/type collection.  Our Eiffel (2.3) gives two
views: interface (via "short") and full implementation (via "cat", "vi",
or any other dumb viewing tools).  There is only one underlying object
corresponding to the single proc/fn collection.  Modula-2 designers
assumed you would have no tools other than editors and file-systems,
so you have to do all the work yourself.

By the way, the "short" view of Eiffel includes
     exported names and signatures
     first comment from each proc/fn
     pre & post condition of each proc/fn
     class invariant of each class (module/type)
     index clause      

Perhaps we should expect even more sophisticated view. For example,
maybe our viewer should offer separate control over each of the above
kinds of information.  Also, ability to define different visibility
to different clients could be incorporated into viewer, i.e., viewer
becomes a client.
 
My own preference is for everything to be done via views, with
viewing tool generating the source code when you hit the compile
button.  But then it might look like Smalltalk, and non-Smalltalkers
(Bigtalkers?) would complain!

Surely syntax errors should be one such view.  And what about
static analysis info?  Or maybe even dynamic profiling?  We should
demand tools in which all this kind of info is integrated and
available through the same interface.

I built my own crude tools years back for doing modular programming
with Pascal and no units/environments/modules or nothing, except
INCLUDE directives.  So my make tool took source code of supplier
module, found type/fn/proc defs and comments and put them in a
"def" file with "extern" for every proc/fn.  I had much fun trying
to work out clever rules for outputting definitions or ignoring
them.  In the end, I went back to my first and simplest idea:
"export" anything starting at start-of-line, and leave the rest
hidden.  No key words embedded in special constants, no special
flags on command line, no module description language to invent..



======================================================================= 74 ===
Date:    Mon, 25 Oct 93 14:55:25 GMT
From:    buschman@slsvaat.sel.de (Andreas Buschmann US/END 60/1/25 Tel.71409)
Subject: Re: Address Operators (was: Why structural equivalence?)

I (Andreas Buschmann) wrote:
    : 1.
ab> You assume here a traced REF like in the current Implementation of
ab> Modula3, which usually points only to the heap. The more generic REF
ab> (like in Algol68) may point anywhere.

Bert Laverman wrote:
bl> This is not a 'more generic ref', it is the UNTRACED REF.

nope, in Algol68 you have garbage collection. You can not have heap
memory objects which are not garbage collected in Algol68.

Peter Klein wrote:
pk> Yes, but REF'ed objects being on the heap is not just a SRC m3
pk> implementation detail, it's necessary for the semantics of the
pk> language.

why?

I didn't find anything in the report which required that any traced
reference is on the heap.


pk> Why do you require a *pointer* to the root pointer? If I walk through
pk> a linked list, I initialize the current pointer to the root pointer
pk> and advance through the list using the "next" links.

To be able tho change the root pointer. (while inserting and deleting) 


ab> You could name this No.4.
ab> 4. lvalue is on the heap, but not allocated by new. It is part of
ab>    something allocated by new.
ab> 5. lvalue is in static memory; it either is a (modul) global variable
ab>    or part of a global variable. (No problems with lifetime here.)

bl> These are both coverd by the ADR() function.

no, ADR() is unsafe and doesn't keep the underlying type.

pk> If it is *intended* to have a pointer to a component of another
pk> object, then why not write exactly this? For your example:
pk>     TYPE REC = RECORD x, y, z := NEW(REF INT); END;
pk>     VAR rec := NEW(REF REC);
pk>     VAR pin := rec.z;

This gives you four memory elements instead of one. This is might be
ok for big elements x, y, z. This is not that a good idea if your
model says that the lifetime of all four memory elements is the
same.

For having lvalue in static memory this wouldn't work any more. x, y
and z would be on the heap then.

				Tschuess
					Andreas
-- 
#include <stddisclaimer.h>

 /|)	Andreas Buschmann
/-|)	SEL Stuttgart US/END

	buschman@us-es.sel.de



======================================================================= 75 ===
Date:    25 Oct 1993 13:41:19 GMT
From:    gwyant@cloyd.east.sun.com (Geoffrey Wyant - Sun Microsystems Labs BOS)
Subject: Re: Address Operators (was: Why structural equivalence?)

>From Andreas Buschmann:
  Peter Klein wrote:
  pk> Yes, but REF'ed objects being on the heap is not just a SRC m3
  pk> implementation detail, it's necessary for the semantics of the
  pk> language.

  why?

  I didn't find anything in the report which required that any traced
  reference is on the heap.

Well strictly speak, the word 'heap' is not used in the description of
traced references. However, it state:

   When all traced references to a piece of storage are gone,
   the implementation reclaims the storage.

While this does not logically entail that traced references cannot
point to stack allocated entities, I imagine it would be safe reading.
By the same token, I think there is the implication (though not entailment)
that traced references cannot point to static entities.

--geoff


--
Geoff Wyant
Geoff.Wyant@east.sun.com
Sun Microsystems Laboratories, Inc.

2 Elizabeth Drive
Chelmsford, Ma.
01824


======================================================================= 76 ===
Date:    Mon, 25 Oct 93 07:39:09 -0700
From:    mhb@src.dec.com ("Marc H. Brown")
Subject: Re: getting SRC-reports


You can get SRC Research Reports via ftp from gatekeeper.dec.com, 
in the directory /pub/DEC/SRC/research-reports. This 
information is also available via the World Wide Web.

Some reports are videotapes or contain color images; for those,
you should send email to src-report@src.dec.com, or write
to "Report Distribution, Digital Systems Research Center,
130 Lytton Ave., Palo Alto, CA 94301."

You can also get (electronic) notification of SRC Reseach Reports;
send email to src-report@src.dec.com. 

Trestle is documented in SRC Research Report #68,
and there's a tutorial in #69. FormsVBT doc isn't 
a SRC Report yet; you can get it from the Modula-3
distribution on gatekeeper in 
    /pub/DEC/Modula-3/release/formsvbt.*.ps.Z





======================================================================= 77 ===
Date:    26 Oct 93 10:36:58
From:    mday@note.lcs.mit.edu (Mark Day)
Subject: Separate interface (was Re: Doctor Dobbs Article)

   grp@dmu.ac.uk (Graham Perkins) writes:

   Yup, I think the documentation tool is the key issue here.  The point
   is that interface and implementation are two different views of the
   same object: a proc/fn/type collection.  Our Eiffel (2.3) gives two
   views: interface (via "short") and full implementation (via "cat", "vi",
   or any other dumb viewing tools).  There is only one underlying object
   corresponding to the single proc/fn collection.  Modula-2 designers
   assumed you would have no tools other than editors and file-systems,
   so you have to do all the work yourself.

I've worked for a number of years in CLU: its associated methodology
makes a distinction between interface and implementation, but in
typical practice a single file is used for both.  

When working in Modula-3 I've found that the need to write an
interface distinct from the implementation has helped me in creating
good modular designs.  It's also been useful to have a distinct
interface in situations where I've had multiple implementations of a
type, typically because I was testing the performance of different
implementation strategies.

These benefits surprised me; my initial reaction to Modula-3 was to
criticize the separate interface as just annoying busywork.

I don't claim that everyone will have this experience; I suspect it's
dependent on the programmer's personality and style.  But I don't
believe that separating the interface out is due only to assumptions
about tool availability.

--Mark Day

mday@lcs.mit.edu


======================================================================= 78 ===
Date:    Tue, 26 Oct 1993 17:32:15 GMT
From:    whitney@oberon.Meakins.McGill.CA ()
Subject: Re: Separate interface (was Re: Doctor Dobbs Article)

Mark Day (mday@note.lcs.mit.edu) wrote:
:    grp@dmu.ac.uk (Graham Perkins) writes:

: I've worked for a number of years in CLU: its associated methodology
: makes a distinction between interface and implementation, but in
: typical practice a single file is used for both.  

: When working in Modula-3 I've found that the need to write an
: interface distinct from the implementation has helped me in creating
: good modular designs.  It's also been useful to have a distinct
: interface in situations where I've had multiple implementations of a
: type, typically because I was testing the performance of different
: implementation strategies.

It is just as easy to prototype designs using languages based on single
source file ( such as Oberon ) by implementing the specification using a
module with  empty procedures.

: These benefits surprised me; my initial reaction to Modula-3 was to
: criticize the separate interface as just annoying busywork.

Having switched from Modula-2 to Oberon, I find that using
seperate interfaces to be tedious and dangerous. ( It is possible to 
change the definition of a module without changing its implementation ).  
I dislike the dependence on system utilities ( make files, project
builders ) to enforce the agreement of module interfaces and 
implementations. Oddly, enough I have fewer compliants ( the personality
thing ) when using similar tools to check the compilation order of
modules.


Whitney


======================================================================= 79 ===
Date:    Wed, 27 Oct 1993 00:02:11 GMT
From:    William Burrow <T0FG@UNB.CA>
Subject: Re: Separate interface (was Re: Doctor Dobbs Article)

In article <1993Oct26.173215.4573@sifon.cc.mcgill.ca> whitney@oberon.Meakins.Mc
Gill.CA () writes:
>: These benefits surprised me; my initial reaction to Modula-3 was to
>: criticize the separate interface as just annoying busywork.
>
>Having switched from Modula-2 to Oberon, I find that using
>seperate interfaces to be tedious and dangerous. ( It is possible to
>change the definition of a module without changing its implementation ).

Well, I'd be second-guessing N. Wirth by noting that seperate
interfaces permit a top-down design approach.  Haven't quite figured
out Oberon's hints yet :) so don't know if that technique is
affected.  (Not that I use that technique.)

Will.


------------------------------ William Burrow
Internet: t0fg@unb.ca                       | If a USENET could net
          will@p1.f100.n255.z1.fidonet.org  | ewes, how many ewes
Fidonet:  1:255/100.1                       | could a USENET net?


======================================================================= 80 ===
Date:    Thu, 28 Oct 1993 12:25:34 GMT
From:    bwbecker@watdragon.uwaterloo.ca (Byron Weber Becker)
Subject: GenList.mg bug

The procedures Find and FindIf in the library file GenList.mg
have a bug.  When GenList is instantiated with a non-reference
type (eg: INTEGER) the compiler (rightly) refuses to compile
	val : Elt.T := NIL;

There doesn't seem to be a work-around without changing the 
interface since NIL is used to signal failure.  With non-reference
types there is no sure-fire value to return as a failure.

Byron Weber Becker

-- 
-----------------------------------------------------------------------------
Byron Weber Becker
bwbecker@watdragon.uwaterloo.ca
-----------------------------------------------------------------------------


======================================================================= 81 ===
Date:    Thu, 28 Oct 1993 13:42:30 GMT
From:    huw@dcs.gla.ac.uk (Huw Evans)
Subject: Modula-3 books


Can you direct me to some good modula3 books.  I am also interested in books th
at
deal with the object oriented design and analysis of problems as a separate top
ic
from modula3 although books that deal with them together are OK.  Also, do you
know of any books that describe how to management an object oriented project ?

Please mail me directly

Thanks


======================================================================= 82 ===
Date:    29 Oct 93 13:12:51 GMT
From:    fn00@gte.com (Farshad Nayeri)
Subject: Re: M3 alpha-3.0 on Linux

tIn article <2a6eb0$h01@src-news.pa.dec.com> kalsow@src.dec.com (Bill Kalsow) w
rites:

   Yes, it's a known problem.  The alpha-3.0 release was intended for
   a few brave pioneers and the curious browsers.  It won't build and
   install correctly on most platforms.

Any brave pioneers want to share their experience with the SPARC 3.0
distribution on the net?  I am anxious to get it up and running here;
unfortunately, I am too busy that I can't spend time on it right now.

Thanks,

--farshad
--
Ensuring a working environment is everyone's responsibility.


======================================================================= 83 ===
Date:    Sat, 30 Oct 1993 19:41:21 GMT
From:    pgs1002@cus.cam.ac.uk (Dr P.G. Sjoerdsma)
Subject: formsvbt Display problem



I have a problem with running formsedit etc.; when I try to run the
program my screen blanks and the following message appears:

'XIO fatal IO error 32 on X server ":0.0"
-- stuff deleted
the conection was probably broken by a server shutdown or KillClient.
/usr/openwin/bin/xinit: connection to X serever lost.
XIO: fatal IO error 32 on X server ":0.0"
after 869 requests (869 known processed) with 0 events remaining.
-- stuff deleted'

What has happened????


System: sun SPARCclassic
OS    : SunOs4.1.3C
gcc 2.5.0
olwm window manager

Modifications:
I included -static -lXmu to go around a well known library bug. This
was added in 'toplevel.tmpl' as -X2@-static@.
This seems to work ok.


Can someone tell me what gas gone wrong, or am I just ignorant or
overlooked the obvious?

Please mail directly since I installed M3 at my new machine which
won't be on the net until december, so I won't have much time to use
GNUS. Anyway I'll repost the answers.


Thanks
Paul
--
                                 ___
                                (o o) 
-----------------------------ooO-(_)-Ooo-----------------------------
        Paul Sjoerdsma, Godwin Laboratory, Free School Lane,
                     Cambridge CB2 3RS England
       fax:   (44) (0)223-334871, email: pgs1002@cus.cam.ac.uk
---------------------------------------------------------------------





======================================================================= 84 ===
Date:    Sun, 31 Oct 1993 15:14:43 GMT
From:    pgs1002@cus.cam.ac.uk (Dr P.G. Sjoerdsma)
Subject: mgkit compile-time error


Thanks to some friendly folks out here, I got trestle working.
Unfortunately I got another error:

Compiling mgkit: MGRd.ir
error:
'as: "/usr/tmp/cca13282.s", line 8: error: location counter not on
word boundary'
'as.. same for line 14'

I use gcc-2.5. I tried some things:
I adapted the /usr/lang/lib/m3/config file:
-- removed optimize flagse (-O)
-- changed CC=gcc to CC=cc
Nothing works

Answers are appreciated!!

Thanks,
Paul
--
                                 ___
                                (o o) 
-----------------------------ooO-(_)-Ooo-----------------------------
        Paul Sjoerdsma, Godwin Laboratory, Free School Lane,
                     Cambridge CB2 3RS England
       fax:   (44) (0)223-334871, email: pgs1002@cus.cam.ac.uk
---------------------------------------------------------------------





======================================================================= 85 ===
Date:    31 Oct 1993 10:22 PST
From:    skulski@csa5.lbl.gov (Wojtek Skulski, LBL phone: (510) 486 7791)
Subject: Re: M3 vs Oberon capabilities

In article <29v26f$8k1@newsflash.mitre.org>, 
crawford@boole.mitre.org (Randy Crawford) writes...
> 
>I've heard tell that some sort of extended variant of Oberon exists
>which *is* an OOPL, but good luck to you finding a compiler.  Better
>to stick with M3 if you feel Modulish.  IMHO, Oberon's heyday is past.

To find a good Oberon compiler would be easy. Just look into 
neptune.inf.ethz.ch, directory Oberon. There are freeware implementations
there for MS-DOS, Windows, Mac, Sun, IBM-6000, Silicon Graphics, 
HP, Amiga, .... And the list is growing. There are also several 
commercial implementations available for different platforms. 
Look at the README file in the same directory for vendor info.

As for the free ETH implementations, they all are incarnations of 
the same complete operating environment containing a powerful multifont 
wordprocessor integrated with a graphics/drawing program, which enables
figures to be embedded into text documents. This is pretty impressive 
by itself, especially because these figures are live and freely editable
"on spot". Not only figures, but live elements of different kinds, 
like pop-up menus, animated clocks, hypertext links and so on. 
Did you ever compile a program containing a ticking clock as a part 
of a comment ? Not only fun, but it also opens interesting new 
horizons as for the way applications are designed and put together.

And what's equally amazing: each of these Oberon implementations 
is packed into about 1 MB. In this amount of disk space there is 
a complete graphic environment, wordprocessor, graphic package, 
compiler, linker and lots of documentation. 

In view of all this Randy's comment is both ill-informed and unwarranted.

> 
>| Randy Crawford        crawford@mitre.org        The MITRE Corporation
>|                                                 7525 Colshire Dr., MS Z421
>| N=1 -> P=NP           703 883-7940              McLean, VA  22102

Wojtek

Wojtek Skulski, Lawrence Berkeley Laboratory, 1 Cyclotron Rd, MS 71-259
Berkeley, CA 94720. SKULSKI@LBL.bitnet (Disclaimer: my opinions are my own.)


======================================================================= 86 ===
Date:    Sat, 30 Oct 93 21:11:45 GMT
From:    gjarvis@timfcbk.isis.org (Greg Jarvis)
Subject: Re: Separate interface (was Re: Doctor Dobbs Article)

mday@note.lcs.mit.edu writes in article <MDAY.93Oct26103658@note.lcs.mit.edu>:
> 
>    grp@dmu.ac.uk (Graham Perkins) writes:
> 
>    Yup, I think the documentation tool is the key issue here.  The point
>    is that interface and implementation are two different views of the
>    same object: a proc/fn/type collection.  Our Eiffel (2.3) gives two
>    views: interface (via "short") and full implementation (via "cat", "vi",
>    or any other dumb viewing tools).  There is only one underlying object
>    corresponding to the single proc/fn collection.  Modula-2 designers
>    assumed you would have no tools other than editors and file-systems,
>    so you have to do all the work yourself.

The most important reason for separate files is the software engineer 
can restrict a programmer from changing an interface to suite his owns
needs by simply giving read only access to the interface file.

> When working in Modula-3 I've found that the need to write an
> interface distinct from the implementation has helped me in creating
> good modular designs.  It's also been useful to have a distinct
> interface in situations where I've had multiple implementations of a
> type, typically because I was testing the performance of different
> implementation strategies.

This second reason results in good modular design resulting in code 
that usually can be reused.


