======================================================================= 1 ===
Date:    2 Jan 1994 08:01:37 GMT
From:    Eric Muller <muller@src.dec.com>
Subject: Re: Quest for Quest

|> Does anyone know whether there exists an implementation
|> of the Quest language described in this research report:

Anonymous ftp to gatekeeper.dec.com:pub/DEC/Quest.

-- 
Eric.



======================================================================= 2 ===
Date:    Sun, 2 Jan 1994 07:44:50 GMT
From:    aet@munta.cs.mu.OZ.AU (Bert THOMPSON)
Subject: Quest for Quest


Hi!

Does anyone know whether there exists an implementation
of the Quest language described in this research report:

	`Typeful Programming', Luca Cardelli

Is Quest similar to Modula3? (I know little about Modula3.)


Cheers,

	Bert.


-----------------------------------------------------------------------
bert thompson					aet@cs.mu.oz.au.
department of computer science 			university of melbourne
-----------------------------------------------------------------------


======================================================================= 3 ===
Date:    2 Jan 1994 01:51:52 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.




-- 
Eric.



======================================================================= 4 ===
Date:    Tue, 04 Jan 1994 10:42:01 +0100
From:    vfrank@vnet3.vub.ac.be (Franklin L. Vermeulen)
Subject: Mac Implementation?

Hi, I read in the FAQ that there currently is no
such thing as a Mac implementation of M3.  But is
*anybody* have plans in that direction?

Thanks
-- 
Franklin L. Vermeulen, Ph.D.
Vesalius College, Vrije Universiteit Brussel
Pleinlaan 2, B-1050 Brussel (Belgium)
Ph: +32 2 641-3493; Fax: +32 2 641-3495; Room 10F735


======================================================================= 5 ===
Date:    13 Jan 1994 23:26:57 GMT
From:    kendall@pot.East.Sun.COM (Sam Kendall - Sun Microsystems Labs BOS)
Subject: Re: Beginners Guide to M3

There are only two books on M3 that I know of.  One is _Modula-3_ by Sam
Harbison, and the other is _Systems Programming with Modula-3_, ed. by
Greg Nelson.  The first one seems to be the one for beginners, although
I haven't looked at it.  The second has the language reference manual
and other articles.

SIGPLAN Notices from August '92 has a copy of the reference manual.

Good luck!

----
Sam Kendall
Sun Microsystems Labs BOS


======================================================================= 6 ===
Date:    13 Jan 1994 23:22:29 GMT
From:    kendall@pot.East.Sun.COM (Sam Kendall - Sun Microsystems Labs BOS)
Subject: Why can I not qualify an identifier within its own interface?

Eg:

    INTERFACE I;
    TYPE T = ...;
    PROCEDURE F(): I.T;	(* must delete `I.' to get this to compile *)
    END I.

Why this restriction?  (I guess the same restriction exists for modules,
though I haven't tried.)

----
Sam Kendall
Sun Microsystems Labs BOS


======================================================================= 7 ===
Date:    Thu, 13 Jan 94 15:49:32 -0800
From:    mhb@src.dec.com ("Marc H. Brown")
Subject: Books on Modula-3 [was: Re: Beginners Guide to M3]


There's a third book on Modula-3:

    Algorithms in Modula-3 
    Robert Sedgewick
    Addison-Wesley, 1993.
    ISBN number is 0-201-53351-0

From the back of the book: "This latest version of Robert Sedgewick's 
popular book exhibits his comprehensive collection of algorithms 
in a modular, object-oriented programming environment with implementations 
in the Modula-3 language. These algorithms cover a broad range of 
fundamental and more advanced methods: sorting, searching, string-processing, 
geometric, graph, and mathematical algorithms." 

Some of the algorithm animations on the DEC SRC Modula-3 release 
on gatekeeper are closely tied to the diagrams for this book. 

The focus of the book is on algorithms and data structures, not on 
programming language constructs. But it does make good use of M3 
objects and interfaces. I highly recommend it!

Marc


======================================================================= 8 ===
Date:    Thu, 13 Jan 1994 06:48:17 GMT
From:    rundle@possum.jrc.flinders.edu.au (Richard Rundle)
Subject: Beginners Guide to M3

Can anyone recommend some easy to get hold of introductory articles on
modula 3 programming?

By easy to get hold of I mean, available electronically, or in journals
or books which libraries have a tendency to hold.

Thanks

Richard   


======================================================================= 9 ===
Date:    14 Jan 1994 13:03:29 GMT
From:    ucaa2385@iris3.csv.ica.uni-stuttgart.de (Peter Hermann)
Subject: Re: CFP: Joint Modular Languages Conference (JMLC)

In article <2h5u2g$i0m@wega.rz.uni-ulm.de> borchert@thales.mathematik.uni-ulm.d
e (Andreas Borchert) writes:
>more recent developments. We cordially invite Pascal, Modula-2, Oberon
>programmers and programming communities from other traditions to join

... and reject Ada people?    ;-)

-- 
Peter Hermann                        Tel: 0711-685-3611
Institut fuer Computeranwendungen    Fax:         -3758 or -3669
Pfaffenwaldring 27      ICA2         e-mail: ph@csv.ica.uni-stuttgart.de
70569 Stuttgart Universitaet             or  ph@ica.uni-stuttgart.d400.de


======================================================================= 10 ===
Date:    14 Jan 1994 11:01:36 GMT
From:    borchert@thales.mathematik.uni-ulm.de (Andreas Borchert)
Subject: CFP: Joint Modular Languages Conference (JMLC)

-------------------------------------------------------------------------------
                              # #     # #        #####
  University of Ulm,          # ##   ## #       #     #    in cooperation with
       Germany                # # # # # #       #
                              # #  #  # #       #            GI, SIG and BCS
                        #     # #     # #       #
 28th-30th  September   #     # #     # #       #     #
        1994             #####  #     # #######  #####

                       Joint Modular Languages Conference
             Formerly the European & International Modula-2 Conference
		          Modula-2, Oberon and Friends
                         Keynote Speaker: Niklaus Wirth
-------------------------------------------------------------------------------
                                CALL FOR PAPERS
                            AND FIRST ANNOUNCEMENT
-------------------------------------------------------------------------------


IN CO-OPERATION WITH:

Gesellschaft fuer Informatik e.V., Fachgruppe 2.1.3, 2.1.4
Schweizer Informatiker Gesellschaft, Fachgruppe Oberon
British Computer Society, Modular Languages SIG

THEME

The time has come for all to take a wider perspective of programming
languages.  Designers, programmers and teachers interested in modular
languages will have the opportunity to become aware of alternative and
more recent developments. We cordially invite Pascal, Modula-2, Oberon
programmers and programming communities from other traditions to join
the conference and share our and their experiences. The scope of the
conference is broad but centered around modular high-level languages
and their effective use.

Papers on recent work in the following areas are invited:

   *	Approaches to modularisation & class design
   *	Module and class libraries & families
   *	Modularity, concurrency & persistence
   *	Safety of programming languages
   *	Comparison of programming languages
   *	Mechanisms for type extension & delegation
   *	Implementation of run-time environments
   *	Safety critical & real-time applications
   *	Programming environments & tool boxes
   *	Life cycle & engineering of program systems
   *	Light-weight systems
   *	Teaching systems & schemes

Accepted papers will be published in the conference proceedings.
Intending authors should submit three copies of an extended abstract
before 15th April 1994 to:

	Peter Schulthess
	Verteilte Systeme, Informatik
	Universitaet Ulm, o-27
	D-89069 Ulm, Germany

	Telefax: +49 731 502 4142
	E-Mail: schulthe@informatik.uni-ulm.de

PROGRAMME COMMITTEE

Peter Schulthess (Chairman, University of Ulm)
Marwan M. Al-Akaidi (De Montfort University, UK)
Andreas Borchert (University of Ulm, Germany)
Randy Bush (PSG, USA)
Steven Collins (Real Time Associates, UK)
James Cooling (Univ. of Loughborough, UK)
Antonio Corradi (University of Bologna, Italy)
Guenther Dotzel (ModulaWare, Germany)
Jacques Farre (Universite de Nice, France)
John Gough (QUT, Australia)
Juerg Gutknecht (ETHZ, Switzerland)
Brian Kirk (Robinson Associates, UK)
Herbert Klaeren (University of Tuebingen, Germany)
Wolfram Lippe (Universitaet Muenster, Germany)
Hans-Peter Moessenboeck (ETHZ, Switzerland)
Libero Nigro (Universita della Calabria, Italy)
Gustav Pomberger (University of Linz, Austria)
Franz Schweiggert (Unversity of Ulm, Germany)
Marjan Spegel (Stefan Institute, Slovenia)
Juergen Uhl (IBM, Germany)

ORGANISING COMMITEE

Alfred Lupper (OC Director, University of Ulm)
Marwan Al-Akaidi (De Montfort University, UK)
Andreas Borchert (University of Ulm)
James Cooling (University of Loughborough, UK)
Peter Schulthess (University of Ulm)
Franz Schweiggert (University of Ulm)

In co-operation with
IBM Deutschland, Development GmbH
Daimler Benz Research Institute, Ulm
NC-Gesellschaft, Ulm
FAW, Ulm

EXHIBITORS

The conference will provide an opportunity for delegates to discuss and
view Modula-2, Oberon, C++ and other language compilers and
environments. Organisations interested in exhibiting compilers and
related products are invited to contact the organising committee.

KEY DATES

	15. April 94		Submission of abstracts
	10. June 94		Notify acceptance to authors
	1. Sept. 94		Submission of final papers
	26.-27. Sept. 94	Tutorials
	28.-30. Sept. 94	Conference

VENUE

The conference will be held at the University of Ulm on campus, which
is situated in the east of Baden-Wuerttemberg, Germany. Ulm and its
University are easily reached by ICE-trains and motorways. Direct
transfers to Stuttgart airport will be organised.

The working language of the conference is English. This will be used
for all presentations and printed material.

SUPPLEMENTARY EVENT AND BANQUET

Particular attention will be given to the organisation of a programme
for accompanying persons:

   Tour of the Ulmer Muenster
   Visit to Reisensburg Castle
   Excursion to the Blautopf springs
   Open air sculpture collection on campus
   Banquet ...

REPLY FORM

	PLEASE COMPLETE IN BLOCK CAPITALS

To:	JMLC Conference Secretary
	Verteilte Systeme, Informatik
	Universitaet Ulm
	Oberer Eselsberg o-27
	D-89069 Ulm, Germany

	Phone#:  +49 731 502 4140
	Telefax: +49 731 502 4142
	vsoffice@informatik.uni-ulm.de

[ ]	I am interested in the conference and require
	copies of the programme and registration form:
 
	Name		_______________________________________

	Organisation	_______________________________________

	Address		_______________________________________

	Telephone, Fax	_______________________________________	

	E-Mail		_______________________________________
 
[ ]	I intend to submit a paper provisionally entitled:

	Title		_______________________________________

			_______________________________________

[ ]	If you know of any other colleague who may be interested,
	please give details below.

	Name		_______________________________________

	Organisation	_______________________________________

	Address		_______________________________________

	E-Mail		_______________________________________


CONFERENCE INFORMATION

General enquiries and requests for detailed information should be
addressed to the JMLC Conference Secretary (address given above).

For technical information, please contact any member of the organising
committee or Prof. Peter Schulthess by one of the following means:

Phone#:  +49 731 502 4140
Telefax: +49 731 502 4142
E-mail:  schulthe@informatik.uni-ulm.de

A full conference programme and registration form will be published
early in June 1994 and sent to those who complete and return the
attached form.

The conference fee is budgeted to approximately DM 350. Discounts will
be available for GI, SI and BCS SIG members and for students.
-- 
_______________________________________________________________________________

Andreas Borchert, University of Ulm, SAI, D-89069 Ulm, Germany
Internet: borchert@mathematik.uni-ulm.de


======================================================================= 11 ===
Date:    17 Jan 94 16:58:07 GMT
From:    cbnorman@undergrad.math.uwaterloo.ca (Chris 'Strunoph' Norman)
Subject: Odd Comment Question

Any idea why the following produces an EOF in comment error?

(*) Comment (*)
-- 
    /|                          (Reverend) Christopher Bruce Norman
\`o.@'   Ack! Ack! Thbbbpppt!              cbnorman@descartes.uwaterloo.ca
=(___)=  				   CS246 Tutor (MC 1014)
   U          "Strip mining prevents forest fires" -- Smokey the Bear


======================================================================= 12 ===
Date:    17 Jan 1994 18:14:27 GMT
From:    mako@FNALA.FNAL.GOV
Subject: Re: Odd Comment Question

> Any idea why the following produces an EOF in comment error?
> 
> (*) Comment (*)

In Moulda-3, comments can nest; the second "(*" is interpreted as the
beginning of the next level of comment line, with no corresponding end
marks!
						mako


======================================================================= 13 ===
Date:    Mon, 17 Jan 1994 18:45:42 GMT
From:    whitney@galileo.Meakins.McGill.CA ()
Subject: Re: Odd Comment Question

Chris 'Strunoph' Norman (cbnorman@undergrad.math.uwaterloo.ca) wrote:
: Any idea why the following produces an EOF in comment error?

: (*) Comment (*)

The EOF is reached before the nested comments are closed.
The problem is easy to see if you add some spaces and/or
change ) for ].  

  (* ] Comment (* ] 
  

whitney


======================================================================= 14 ===
Date:    17 Jan 94 20:38:38 GMT
From:    cbnorman@undergrad.math.uwaterloo.ca (Chris 'Strunoph' Norman)
Subject: Re: Odd Comment Question

In article <2heki3$dr6@fnnews.fnal.gov>,  <mako@FNALA.FNAL.GOV> wrote:
>> Any idea why the following produces an EOF in comment error?
>> 
>> (*) Comment (*)
>
>In Moulda-3, comments can nest; the second "(*" is interpreted as the
>beginning of the next level of comment line, with no corresponding end
>marks!
>						mako

(smacks self in head)

Of course.  Thanks.
-- 
    /|                          (Reverend) Christopher Bruce Norman
\`o.@'   Ack! Ack! Thbbbpppt!              cbnorman@descartes.uwaterloo.ca
=(___)=  				   CS246 Tutor (MC 1014)
   U          "Strip mining prevents forest fires" -- Smokey the Bear


======================================================================= 15 ===
Date:    17 Jan 1994 19:07:08 -0500
From:    clarence@orion.cc.andrews.edu (Clarence L. Thomas IV)
Subject: Global Alert For All: Jesus is Coming Soon

The earthquake in Los Angeles, California, the flood in Europe, the seemingly
unstoppable war in the former Yugoslavia, the devastating fires in Australia,
the flood in the Midwest of the United States of America, the devastating fires
near Los Angeles, California, the rapid and appalling increase in violence in
cities, towns, villages all over the world, the famines, the diseases, the rapi
d
decline of the family unit, and the destructive earthquake in India (in 1993)
are signs that this world's history is coming to a climax. The human race
has trampled on God's Constitution, as given in Exodus 20:1-17 (King James
Version Bible), and Jesus is coming to set things right. These rapidly
accelerating signs are an indication that Jesus is coming soon (Matthew 24).

God's Holy Spirit is gradually withdrawing its protection from the earth
and the devastating events you see are demonstrations of Satan's power. All
those who are not guarded by God are in danger of forever losing eternal life.

If you want to know what's about to happen, please study the books of Daniel
and Revelation which are located in God's Word, the Bible.  They are not
sealed or closed books. They can and must be understood by all. Every word
in the Bible from Genesis to Revelation is true. The Bible and the Bible only
must be your guide.

When God's Law (the Constitution for the Universe) is consistently ignored, 
disregarded, changed, and questioned, He permits certain events to occur to 
wake us up.  I would urge all, wherever you are and regardless of the 
circumstances, to directly call on Jesus and ask Him to intervene in your life.
Jesus who created this planet and every living creature in it and on it, died 
on the cross, was raised from the dead by God the Father, and is now in Heaven
interceding for you. Jesus is the only One who can rescue us from the slavery,
misery, and death Satan is causing us.

For reference I'm including God's Constitution as given in the King James
Version Bible. Please note that when God says the seventh day, he means Sabbath
(the 7th day of the week) not Sunday (1st day of the week).

Commandment #1:  Exodus 20:1-3 (KJV)  And God
                 spake all these words, saying, I am         
                 the LORD thy God, which have brought
                 thee out of the land of Egypt, out
                 of the house of bondage. Thou shalt have
                 no other gods before me.

Commandment #2:  Exodus 20:4-6 (KJV) Thou shalt not make
                 unto thee any graven image, or any
                 likeness of any thing that is in heaven
                 above, or that is in the earth beneath,
                 or that is in the water under the earth.
                 And shewing mercy unto thousands of them
                 that love me, and keep my commandments.

Commandment #3:  Exodus 20:7 (KJV) Thou shalt not take
                 the name of the LORD thy God in vain;
                 for the LORD will not hold him
                 guiltless that taketh his name in vain.

Commandment #4:  Exodus 20:8-11 (KJV) Remember the sabbath
                 day, to keep it holy. Six days shalt thou
                 labour, and do all thy work: But the
                 seventh day is the sabbath of the LORD
                 thy God: in it thou shalt not do any
                 work, thou, nor thy son, nor thy daughter,
                 thy manservant, nor thy maidservant, nor
                 thy cattle, nor thy stranger that is
                 within thy gates: For in six days the
                 LORD made heaven and earth, the sea, and
                 all that in them is, and rested the seventh
                 day: wherefore the LORD blessed the sabbath
                 day, and hallowed it.

Commandment #5:  Exodus 20:12 (KJV) Honour thy father and thy
                 mother: that thy days may be long upon the
                 land which the LORD thy God giveth thee.

Commandment #6:  Exodus 20:13 (KJV) Thou shalt not kill.

Commandment #7:  Exodus 20:14 (KJV) Thou shalt not commit
                 adultery.

Commandment #8:  Exodus 20:15 (KJV) Thou shalt not steal.

Commandment #9:  Exodus 20:16 (KJV) Thou shalt not bear
                 false witness against thy neighbour.

Commandment #10: Exodus 20:17 (KJV) Thou shalt not covet
                 thy neighbour's house, thou shalt not
                 covet thy neighbour's wife, nor his
                 manservant, nor his maidservant, nor
                 his ox, nor his ass, nor any thing that
                 is thy neighbour's.

I also recommend that the following books be obtained and closely studied:

         The Great Controversy
         By Ellen G. White
         Review and Herald Publishing Association
         Hagerstown, MD 21740

	 The Desire of the Ages
	 By Ellen G. White
	 Review and Herald Publishing Association
	 Hagerstown, MD 21740

         Patriarchs and Prophets
         By Ellen G. White
         Review and Hearld Publishing Association
         Hagerstown, MD 21740

	 Daniel and the Revelation
         By Uriah Smith
         Review and Herald Publishing Association
         Hagerstown, MD 21740
-------
Clarence L. Thomas IV
Phone:  616-471-6116
E-mail: thomas@redwood.cc.andrews.edu


======================================================================= 16 ===
Date:    18 Jan 94 23:07:40 -0500
From:    Joe.Klemmer@f370.n109.z1.fidonet.org (Joe Klemmer)
Subject: DOS M3 'compiler'

    I grabbed what perports to be a DOS version of a Modula-3 compiler off of
ftp.luth.se in pub/pc/msdos/languages/modula3.  The files are in DOS 'Backup'
format.  I 'Restored' them to their original format and found that there was
supposed to be an INSTALL.BAT file with them that was not there.  I believe I
can fake this (the files are just TAR's of the M3 & DJGPP trees).

    What I'd like is if anyone has played with this version at all?  Any info
that anyone might have on this would be appriciated.

Later,
Joe


======================================================================= 17 ===
Date:    18 Jan 1994 07:13:30 GMT
From:    laszlo@post.ifi.uni-klu.ac.at (Laszlo BOESZOERMENYI)
Subject: Re: Beginners Guide to M3

We are working on a book with the title:

"Programming with Style -
Introduction into programming with Modula-3"

The book is intended first of all for university students.
It will come out first in German, this autumn,
the English translation will follow as fast as possible.
(I hope at the begining of the next year.)
It will be published at the Springer Verlag.

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


======================================================================= 18 ===
Date:    20 Jan 94 02:22:03 GMT
From:    kmc2lee@undergrad.math.uwaterloo.ca (Kennis)
Subject: Re: DOS M3 'compiler'

In article <330_9401182357@blkcat.fidonet.org>, Joe.Klemmer@f370.n109.z1.fidone
t.org (Joe Klemmer) writes:
>     I grabbed what perports to be a DOS version of a Modula-3 compiler off of
> ftp.luth.se in pub/pc/msdos/languages/modula3.  The files are in DOS 'Backup'
> format.  I 'Restored' them to their original format and found that there was
> supposed to be an INSTALL.BAT file with them that was not there.  I believe I
> can fake this (the files are just TAR's of the M3 & DJGPP trees).
> 
>     What I'd like is if anyone has played with this version at all?  Any info
> that anyone might have on this would be appriciated.
> 
> Later,
> Joe

Sorry, I'm not going to answer your question and I don't the answer either.
I just have some other questions.  How large is the full system after 
restored?  Is it fully compatible with the SRC Modula3?

Thanks.

-Kennis
 kmc2lee@descartes.uwaterloo.ca


======================================================================= 19 ===
Date:    20 Jan 94 10:56:49 EET
From:    kolu@tnclus.tele.nokia.fi
Subject: Exception handling in Modula-3?

Hello!

I'm trying to do a comparison on exception handling methods in 
different programming languages. I'm now looking for information 
on exception handling in Modula-3. Is there anybody who could help me? 
                           
Thank you!

                Minja


======================================================================= 20 ===
Date:    Thu, 20 Jan 1994 11:39:54 GMT
From:    dns11@cus.cam.ac.uk (D.N. Sann)
Subject: TextPorts, VTexts and MTexts.

I am implementing an Editor and I would like the ability to
split the screen to edit two parts of the same document simultaneously.
Currently I have a single textEdit as the editing window. The underlying
TextPort does not allow for splitting the window. I can see that a 
VText has the capability to split but I am not supposed to change the 
VText in a textport.
I thought that having a second textport with the Vtext set to point to
the original Textport's VText might work. However since the VText holds
info about where it is displayed I think it will not work.
As a second Idea I thought that having the VTexts from the two textports
point to the same MText. This is Plausable but The internals of the Vtext
such as Selections and Markers would be different.(and also it's probably illeg
al)

Is there any way to do this without having to rewrite the textport?
(Which I probably couldn't do anyway!!)

Cheers Dave.


======================================================================= 21 ===
Date:    Thu, 20 Jan 1994 13:14:53 GMT
From:    whitney@galileo.Meakins.McGill.CA ()
Subject: Re: Exception handling in Modula-3?

kolu@tnclus.tele.nokia.fi wrote:
: Hello!

: I'm trying to do a comparison on exception handling methods in 
: different programming languages. I'm now looking for information 
: on exception handling in Modula-3. Is there anybody who could help me? 


Exception handling in computer languages was covered in 
Andrew Black's  Phd thesis. It is an old thesis ( 1982 )
but it is still worth a read.

Exception Handling: The Case Against
Andrew P. Black
Department of Computer Science
University of Washington
Seattle, WA 98195
USA


Whitney


======================================================================= 22 ===
Date:    Thu, 20 Jan 94 12:01:18 -0800
From:    mhb@src.dec.com ("Marc H. Brown")
Subject: Re: TextPorts, VTexts and MTexts.


You can use a JoinedVBT to allow a VBT to be installed in more than 
one place. To see how this work, check out the implementation of 
ViewportVBT: it allows a user to see multiple views of its child 
by option-clicking in the scrollbar. 

You are correct to notice that there is *a lot* more functionality 
in VText (and MText) than is currently used by the layers above it. 
These libraries were written in the mid-80's in Modula-2, and translated 
mostly mechnically into Modula-3. They are in dire need of redesign 
(and reimplementation).


======================================================================= 23 ===
Date:    20 Jan 94 08:03:21 -0500
From:    Joe.Klemmer@f370.n109.z1.fidonet.org (Joe Klemmer)
Subject: DOS M3 'compiler'

Kennis wrote in a message to All:

>     I grabbed what perports to be a DOS version of a Modula-3 compiler off
of
> ftp.luth.se in pub/pc/msdos/languages/modula3.  The files are in DOS
'Backup'
> format.  I 'Restored' them to their original format and found that there
was
> supposed to be an INSTALL.BAT file with them that was not there.  I believe
I
> can fake this (the files are just TAR's of the M3 & DJGPP trees).
>
>     What I'd like is if anyone has played with this version at all?  Any
info
> that anyone might have on this would be appriciated.

K> Sorry, I'm not going to answer your question and I don't the
K> answer either. I just have some other questions.  How large
K> is the full system after  restored?  Is it fully compatible
K> with the SRC Modula3?

That's cool, I understand.  As to your questions, after instellation it's
about 80MB (or so it clames).  And as to SRC compatability...  I have no
idea, haven't untar'd the files yet to see what the read me says.

I'll keep anyone posted of my progress if anyone cares.

Later,
Joe


======================================================================= 24 ===
Date:    21 Jan 1994 14:51:55 -0000
From:    aps@ecs.soton.ac.uk (Adrian Smith)
Subject: Are "network objects" available yet?

Hi,

I've been using M3 threads to build simple models of parallel/
distributed systems. I'd like to try my hand with some new
mechanisms :-)

Notes with the M3 compiler from DEC imply that "network objects"
are/will be available. Can anyone give me the current status of
development of these abstractions?

Thanks in anticipation,

Adrian
-- 
* Adrian Smith (aps@ecs.soton.ac.uk) *
* Electronics and Computer Science   *
* Southampton University             *
* SOUTHAMPTON SO5 NH                 *


======================================================================= 25 ===
Date:    22 Jan 94 07:26:20 GMT
From:    khaw@parcplace.com
Subject: ParcPlace job opening

ParcPlace is looking for experienced software developers who seek a
change of pace and would be interested in technical support. For
details, please see the posting in ba.jobs.offered

Apologies to those seeing this posting outside the San Francisco Bay
Area. There seems to be some problem with our news transport system
handling Distribution: headers correctly.
--
Michael Khaw	khaw@parcplace.com (or khaw%parcplace.com@netcom.com)
ParcPlace Systems, Sunnyvale, CA	PRODUCT INFO: info@parcplace.com


======================================================================= 26 ===
Date:    Sat, 22 Jan 1994 15:05:42 GMT
From:    robsch@robkaos.GUN.de (Robert Schien)
Subject: M3 for 386BSD/NetBSD/FreeBSD

Is there a version of M3 for 386BSD/NetBSD/FreeBSD? Perhaps
even a native 386 compiler? But a M3-to-C converter would
be already nice.

Thanks in advance.
Robert


======================================================================= 27 ===
Date:    Sun, 23 Jan 1994 23:29:32 GMT
From:    ftcvb@aurora.alaska.edu
Subject: Re: DOS M3 'compiler'

In article <330_9401182357@blkcat.fidonet.org>, Joe.Klemmer@f370.n109.z1.fidone
t.org (Joe Klemmer) writes:
>     I grabbed what perports to be a DOS version of a Modula-3 compiler off of
> ftp.luth.se in pub/pc/msdos/languages/modula3.  The files are in DOS 'Backup'
> format.  I 'Restored' them to their original format and found that there was
> supposed to be an INSTALL.BAT file with them that was not there.  I believe I
> can fake this (the files are just TAR's of the M3 & DJGPP trees).
> 
>     What I'd like is if anyone has played with this version at all?  Any info
> that anyone might have on this would be appriciated.
> 
> Later,
> Joe

This sounds very much like a repackaged version of m3pc, available from
gatekeeper.dec.com, and mentioned in the FAQ.  I tried this out briefly.
I'm not sure I had it set up right.  It took about 5 minutes to compile
the "hello" sample program into a 300K+ executable file.  I lost interest.
Perhaps someone who is familiar with this could tell me whether the 300k 
files are normal or what I had set up wrong.
--Chase Brady  FTCVB@AURORA.ALASKA.EDU



======================================================================= 28 ===
Date:    24 Jan 1994 09:16:16 GMT
From:    carsten@post.ifi.uni-klu.ac.at (Carsten WEICH)
Subject: Re: DOS M3 'compiler'


Modula-3 on PC:

Modula-3/PC is a fully SRC-compatible compiler. It is based on the version 2.09
 of the
SRC-compiler and does not support threads. The PC-compiler depends on the djgpp
-
(gnu)-C-compiler. You will need a strong PC with about 8 MByte of RAM and 20 MB
yte
free on your disk.

300 KByte hello-world is normal. This is because of the huge Modula-3 library l
inked to
every program.

5 min translation time for hello-world means that you have not granted enough m
emory
to the C-compiler. Giving 6-10 MByte to SMARTDRV (the standard PC disk-cache,
I think it is part of WINDOWS) speeds up things significantly. You should end w
ith
turn-around time of less than a minute for the compilation and linking of a sin
gle module.

We have built a new version of the PC-compiler which is ready but not yet insta
lled
at the gatekeeper. It is better documented and will only require 20 MByte of yo
ur
disk-space. But you need a mathematic-coprocessor or a 80486.

I hope this made thinks clearer.

	Carsten Weich

--------------------------------------
carsten@ifi.uni-klu.ac.at
Carsten Weich
Universitdt Klagenfurt
Austria


======================================================================= 29 ===
Date:    Mon, 24 Jan 1994 08:37:03 GMT
From:    skj@oasis.icl.co.uk (Simon Johnston)
Subject: Linux Modula-3

Hi all I did pick up and start with the alpha-3.0 Linux port, however I found
lots of problems, I have now built it but when I run m3 <filename> I get a
message along the lines of 'possible segmentation violation' and a core file
which grows until it takes all available disk space, and the process is 
taking all the mill. Can anyone help me, please !


MODULE Sig;
FROM ICL IMPORT StdDisclaimer;
FROM Interests IMPORT Modula2, Modula3, Linux, OS2;

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  : 7261 6320    OP Mail: S.K.Johnston@BRA0801|RG12 8TJ           |
`------------------------------------------------------------------------ *)
END Sig.


======================================================================= 30 ===
Date:    24 Jan 1994 17:42:59 +0100
From:    agulbra@nvg.unit.no (Arnt Gulbrandsen)
Subject: Re: Inheritance and Exceptions

In article <2i0nds$e6@urmel.informatik.rwth-aachen.de>,
Peter Klein <pk@rwthi3.informatik.rwth-aachen.de> wrote:
<about exceptions in M3>
>Generally, this is quite sensible, because in a statically typed language,
>the client of an object has to be able to determine the exceptions which
>can result from a method call by the static type of the object, which
>may be a supertype of the actual (dynamic) object's type. On the other
>hand, it is very common that the implementation of a subtype is more
>"complex" than that of the supertype; often, the redefined method calls
>the supertype's method and does "something more". So, the implementation
>of the subtype's method commonly requires _more_ exceptions in the
>raises set, not less.

You have to differentiate between implementation on one hand and
interfaces on the other hand.

The M3 solution "forces" you to regard a subtype as a specialisation
of its supertypes.  The supertype must be more generic than any of
its subtypes.  Expressed like that, it sounds very acceptable to
me.

Of course, it means that the raises set of an abstract class must be
rather large, since it ideally should encompass all implementations
of a specialisation of the interface.

>The only solutions to this problem I can think of are the following:
>
>- All exceptions which may occur in any specialization of a method
>  are already in the raises set of the base class. Problem: The base
>  class has to be changed if a new subtype wants to raise a new exception.

True, but that's a fairly major design change.  It could change the
interfaces of many classes/modules, and is something you should
attempt to avoid when you first write the raises set.  Design is
hard, programming is hard, and there is no magic wand to make it
easy.

>  Furthermore, a method implementation in the "middle" of the inheritance
>  hierarchy still doesn't see which exceptions might be raised by the
>  method of the superclass.

Well, could it anyway?  It only knows the interface, not the
implementation, of its superclass, and hardly even that about any
super-super-super-classes it might have.

All this is IMAO, of course, and I'm nobody in particular.

--Arnt


======================================================================= 31 ===
Date:    24 Jan 1994 14:53:48 GMT
From:    pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
Subject: Inheritance and Exceptions

Hello world!

The following problem now bothers me for some time. I'll use the terminology
of Modula-3 in the following, though the problem is language-independent.

In Modula-3, the exceptions which may be raised during the execution of a
method is called the _raises set_ of the method and is part of the method's
signature. As exceptions are somehow an "output" of the method, they are
subject to the covariance rules, i.e. the raises set of a redefined method
in a subtype must be a subset of the raises set of the method in the
supertype.

Generally, this is quite sensible, because in a statically typed language,
the client of an object has to be able to determine the exceptions which
can result from a method call by the static type of the object, which
may be a supertype of the actual (dynamic) object's type. On the other
hand, it is very common that the implementation of a subtype is more
"complex" than that of the supertype; often, the redefined method calls
the supertype's method and does "something more". So, the implementation
of the subtype's method commonly requires _more_ exceptions in the
raises set, not less.

The only solutions to this problem I can think of are the following:

- All exceptions which may occur in any specialization of a method
  are already in the raises set of the base class. Problem: The base
  class has to be changed if a new subtype wants to raise a new exception.
  Furthermore, a method implementation in the "middle" of the inheritance
  hierarchy still doesn't see which exceptions might be raised by the
  method of the superclass.

- All methods have the "infinite" raises set ANY. Problem: Nobody knows
  which exceptions can be raised by calling a method (or you figure it
  out manually).

Both are quite unsatisfactory. Is there anybody out there with a better
idea?

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




======================================================================= 32 ===
Date:    Mon, 24 Jan 1994 21:18:33 GMT
From:    jmeehan@mendoza.adobe.com (Jim Meehan)
Subject: Re: Inheritance and Exceptions


Modula-3 exceptions aren't objects (for better or worse), but their
arguments can be.  I've written lots of code that used this, and while
not perfect, it's quite reasonable.  For example, subtypes of the
exception-argument type typically override a "print" method to get
more (or less) detailed error messages. 

Jim



======================================================================= 33 ===
Date:    Mon, 24 Jan 94 16:35:40 -0800
From:    heydon@src.dec.com
Subject: Re: Are "network objects" available yet?

> Notes with the M3 compiler from DEC imply that "network objects"
> are/will be available. Can anyone give me the current status of
> development of these abstractions?

To the best of my knowledge, the network object design and implementation are
complete. I don't believe they are currently available; the plan is to include
them as part of the SRC Modula-3 3.0 release. The best reference on network
objects is the following SOSP paper:

  Andrew Birrell, Greg Nelson, Susan Owicki, and Edward Wobber. "Network
  Objects." In 14th ACM Symposium on Operating Systems Principles, pages
  217-230, December, 1993.

- Allan

-------------------------------------------------------------------------------
Allan Heydon					heydon@src.dec.com
DEC Systems Research Center			(415) 853-2142
130 Lytton Ave.					(415) 853-2104 (FAX)
Palo Alto, CA 94301
-------------------------------------------------------------------------------


======================================================================= 34 ===
Date:    24 Jan 1994 20:28:58 GMT
From:    pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
Subject: Re: Inheritance and Exceptions


>>- All exceptions which may occur in any specialization of a method
>>  are already in the raises set of the base class. Problem: The base
>>  class has to be changed if a new subtype wants to raise a new exception.
>
>True, but that's a fairly major design change.  It could change the
>interfaces of many classes/modules, and is something you should
>attempt to avoid when you first write the raises set.

Of course, it may change many interfaces, but it's definitely not a
major design change.

> Design is
>hard, programming is hard, and there is no magic wand to make it
>easy.
>

Thanks for the hint, I almost forgot :)

>>  Furthermore, a method implementation in the "middle" of the inheritance
>>  hierarchy still doesn't see which exceptions might be raised by the
>>  method of the superclass.
>
>Well, could it anyway?  It only knows the interface, not the
>implementation, of its superclass, and hardly even that about any
>super-super-super-classes it might have.
>

This is not completely true. Thanks to the covariance rule, the compiler
can (and does) warn you about unhandled exceptions. So, if an exception
can be raised by a method and it is not in the raises set of the method's
declaration, you'll get a warning. If the modules of the inheritance
hierarchy compile without warning, the raises set visible in the interface
is indeed a superset of the exceptions which may result from the method
call.

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




======================================================================= 35 ===
Date:    Mon, 24 Jan 1994 18:29:53 GMT
From:    hughes@twostep.cs.uiuc.edu (Eric Hughes)
Subject: Re: Inheritance and Exceptions

It seems to me that, although subclass methods will test for _more_ exceptions,
the question is whether the exceptions tested will be derived from exceptions
that can be raised by the superclass method.  In other words, if the subclass
method raises exception type A and the superclass raises exception type B,
is A a subtype of B?  This viewpoint may be an artifact of the (proposed)
implementations I've seen.

Regards,
[][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]
Eric Hughes    2231 DCL    1304 W. Springfield     Urbana, IL  61801  USA
voice: +1 (217) 244-7117   fax: +1 (217) 333-3501  email: hughes@cs.uiuc.edu


======================================================================= 36 ===
Date:    Tue, 25 Jan 1994 01:00:08 GMT
From:    whitney@galileo.Meakins.McGill.CA ()
Subject: Re: Inheritance and Exceptions

From the thesis
	Insight ETHOS:
	On Object-Orientation in Operating Systems.
	by Clemens A. Szyperski
	ISBN 3 7281 1948 2. 

".. exception handling of some kind is crucial for extensible
systems. The point was that the correctness of an extension
called from the within a base service cannot be guaranteed.
Hence, the calling service will need to handle exceptions
occuring during of the extension, if it has to guarantee 
invariants.
   The main problem with exception handling are: How to
handle the complicated flow of control that results if an
exception occuring at one place is caught at another, and how
exceptions interact with a strong typing scheme. In principle
one may introduced a language feature to handle exceptions,
eg. similar to Modula-3:

TRY Si EXCEPT e0 => T0 | e1 => T1 | .. en-1 => Tn-1 END;
Sk

Here Si is a statement that may raise an exception. If it
terminates normally, execution proceeds with statement Sk.
However, if one of the exception, say ej is raised, the
respective handling statement Tj is executed before continuing
with Sk. If an exception occurs which is not listed, or if a
handler raises an exception, or if a handler raises an 
exception, the TRY statement itself raises the exception.
  A problem is: How can a programmer of the TRY statement
know which kind of exceptions can occur. If Si invokes
a late-bound procedure, the possible exceptions that can be 
raised need be declared together with the signature of the
procedure, and occurrence of other exceptions would have to be
prevented by the conpiler. In conjunction with extensions,
declaration of possible extensions becomes problematic. For
example, a procedure P bound to type T may be declared to
 raise exceptions out a set Ep. Then, for a subtype T' of T
, an overiding procedure P' is forced to raise exceptions
of a set Ep', where Ep' <= Ep must hold. This exhibts a conflict:
On the one hand, the procedure refined operations and may 
meaningfully raise new exceptions. On the other hand, the
base type type may be the only one known to the client, and
guarantees that only exceptions out Ep will be raised. Since
the exception set may be considered the type of an out-parameter
of an exception raising procedure, the described conflict is
just a special case of the covariance problem."
   
: > Design is
: >hard, programming is hard, and there is no magic wand to make it
: >easy.

ETHOS is an operating system implemented in Oberon-2. Exception 
handling is not introduced at the language level but rather 
is offered by the system.


Whitney


======================================================================= 37 ===
Date:    Tue, 25 Jan 1994 15:13:28 GMT
From:    k1xe@unb.ca (ZINCK T)
Subject: Modula-2 test code...


Hello !

I am in the process of writting a M2 static analysis toolkit for an undergradut
e 
report. I am writting, basically, the front end on a M2 compiler.

I have several pieces of code to use for testing, but I was wondering if any co
mplete
test code is available, shareware of course.

Please email any information.

Thanx,

Tom Zinck
-------------------------------------------------------------------------------
----
k1xe@unb.ca	University of New Brunswick	Faculty of Computer Science


======================================================================= 38 ===
Date:    Thu, 27 Jan 1994 01:09:25 GMT
From:    norman@flaubert.bellcore.com (Norman Ramsey)
Subject: Generic and exceptions


I have written an interpreter for an extension language, and clients
can add procedures to the extension language.  The problem is with the
type of those procedures.  At the moment the signature is

  PROCEDURE (interpreter:T) RAISES {E}

but that's inconvenient if there are other exceptions a procedure
raises.  I would like to make it generic, e.g.

  GENERIC INTERFACE Interp(Errors);
  
    TYPE T = OBJECT ...
    EXCEPTION E (...);
    ...  
    PROCEDURE (interpreter:T) RAISES {E, Errors.E}
    ...
  END Interp.

but this isn't much better, because I'm trying to adapt existing code
which could raise any of several exceptions.  I could adopt a scheme
by which my code raises only the One True Exception, using the
argument to distinguish different causes.  I've heard this scheme
advocated here, but the scheme in the SRC library is quite
different---interface designers seem to feel free each to export one
or more exceptions.


What all this suggests to me is that the language is weak in this
spot.  Designers of the Next Twelve Changes take note!

  If I could create such a thing as a CONST Exns = ``list of
  exceptions'', and if I could use it in a RAISES clause, then that
  would help a lot, and it shouldn't cause any problems with the language.

  There's no way to say that a procedure raises only the exceptions
  raised by some procedure argument, e.g. for List.Map
    PROCEDURE Map( l: T; p: MapProc; arg: REFANY := NIL ): T RAISES {OF p};
  which I realize equates to ANY in the general case, but often one
  can do better, e.g., because at most call sites p is a constant.

  Maybe there shouldn't be a distinction between exceptions and object types?
  (I'm a rank amateur prepared to believe there may be type-theoretic 
  reasons not to do this, but it would be nice to have the issue explained
  by the pros.)

Comments are welcome.
--
Norman Ramsey
norman@bellcore.com


======================================================================= 39 ===
Date:    Fri, 28 Jan 1994 16:19:15 GMT
From:    fn00@gte.com (Farshad Nayeri)
Subject: GIF to Image.Raw format


Does anyone out there have some code that can read a stream of GIF
data from an "Rd.T" in Modula-3? (I am trying to convert GIF data
coming over a network stream into an "Image.Raw" to display.)

I know that the "Image" interface reads ppm format, and there are UNIX
filters for gif to ppm conversion, but doing it by using UNIX pipes
and/or "system" call seems a bit ugly. 

Thanks! --farshad


--
  ///                       |
 {@,@}                      |  "He's so unhip that when you 
 (...)     Farshad Nayeri   |   say Dylan, he thinks you're
  " "      nayeri@gte.com   |   talking about Dylan Thomas."


======================================================================= 40 ===
Date:    28 Jan 1994 13:25:28 GMT
From:    carsten@post.ifi.uni-klu.ac.at (Carsten WEICH)
Subject: New version of Modula-3/PC


 NEW VERSION OF M3-PC 
 --------------------


We are happy to announce that Carsten Weich, University of Klagenfurt, 
has completed an adavanced version of PC-Modula-3.
The new version is smaller, faster and more comfortable.
It is available on the gatekeeper!
Please find necessary information appended.
(Further approvements are still in progress - do hope!)

	Laszlo Boszormenyi

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

We have built a new version of Modula-3 running on a PC.
You will need a PC:
  *  80486 or 80386 with floatingpoint-coprocessor,
  *  at least 4 but preferable 8 MByte of RAM,
  *  20 MByte discspace free at least.

You can run a modified Modula-3 version 2.09 without thread-
support. Our version features:
  *  support for Unix-like long filenames
  *  automatic compilation (to substitute the lack of m3make)
  *  library to access DOS-files and directories.

We have built a little shell which translates the long filenames you
type in into DOS-filenames. It has a unix-lookalike "ls"-command.
There are commands to teach the system new long filenames.
You can savely move such files around through DOS-directories
(which was not possible with the first version).

This version accesses DOS-files significantly faster than the first
version. Especially linking large Modula-3 programs is much faster
now. On a 50 MHz 80486 with 16 MByte of RAM we measured
a turn-around time of 2 minutes for a 5 module, 500 lines program.
If you want to compile only one module you will have to wait
about one minute.

The necessary files are available at "gatekeeper.dec.com" in
/pub/DEC/Modula-3/contrib/m3pc:

	Install.txt	please read this first!
	djgpp.tar	the DJGPP-gnu-C-compiler
	m3.tar		compiler binaries
	m3src.tar	sources of the compiler (optional)
	tar.exe		program to unpack these files


======================================================================= 41 ===
Date:    29 Jan 94 20:05:01 GMT
From:    toref@dcs.glasgow.ac.uk (Tor Erlend Fagri)
Subject: Calling object methods by reference

I would like to know the readers opinion on the following problem:

Given two objects A and B, maybe of different classes, and given that 
each of these two objects have access to a reference (the address)
of a third object C. How can I make calls in C from both A and B? Or,
is it possible? As far as I can read out of the Modula-3 report, the
only way to call a method in a object is by direct reference, i.e.
<object>.<method>.

I my case, objects A and B would be active (threads), wanting to call
methods in a passive object C.

Thanks for any help.
-- 
  Tor E. Faegri           (e-mail: toref@dcs.gla.ac.uk)


======================================================================= 42 ===
Date:    Fri, 28 Jan 1994 03:32:05 GMT
From:    anders@cs.su.oz.au (Anders Lindstrom)
Subject: M3 for Solaris

Does anyone know if SRC plans to port Modula-3 to the new SPARCserver
1000's running Solaris 3.2? We are looking at using it for undergraduate
teaching next year (1995).

Thanks in advance,

Anders.

--

Anders Lindstrom				Phone:	+61 2 692 4174
Basser Department of Computer Science		Fax:	+61 2 692 3838
Madsen Building F09
University of Sydney NSW 2006
Australia
--

Anders Lindstrom				Phone:	+61 2 692 4174
Basser Department of Computer Science		Fax:	+61 2 692 3838
Madsen Building F09


======================================================================= 43 ===
Date:    Mon, 31 Jan 1994 20:21:56 GMT
From:    jvichere@undergrad.math.uwaterloo.ca (Jan Vicherek)
Subject: Modula3 -> C/++ (for Linux)

  Hello. Does anybody know anything about a Modula3 -> C/++ translator,
eventually it's Linux port ?

 Thanx,
 Jan



======================================================================= 44 ===
Date:    31 Jan 1994 21:26:45 GMT
From:    schilit@parc.xerox.com (Bill Schilit)
Subject: Re: Regular expressions

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


>Is there regular expression matching implemented for M3?? I looked at
>Lex.i3 but couldn't find anything.

>Any pointers are appreciated


	beta.xerox.com:/pub/schilit/m3regex.tar.Z

- Bill
--


