======================================================================= 1 ===
Date:    01 Apr 1995 05:33:44 GMT
From:    schwartz@galapagos.cse.psu.edu (Scott Schwartz)
Subject: Re: need font-lock support for modula3 mode in lemacs

umesh@fugue.lcs.mit.edu (Umesh Maheshwari) writes:
| Does anyone have a nice "modula3-font-lock-keywords" to color modula-3
| programs in lucid emacs?

Big colored capital letters sounds really unappealing.  Better to put
them in a small font, which will simulate the easy to read style of
lower case keywords.

(Simulated ergonomics.  Cool!)



======================================================================= 2 ===
Date:    1 Apr 95 17:42:07
From:    nayeri@gte.com (Farshad Nayeri)
Subject: Re: need font-lock support for modula3 mode in lemacs

In article <SCHWARTZ.95Apr1003344@galapagos.cse.psu.edu> schwartz@galapagos.cse
.psu.edu (Scott Schwartz) writes:

   umesh@fugue.lcs.mit.edu (Umesh Maheshwari) writes:
   | Does anyone have a nice "modula3-font-lock-keywords" to color modula-3
   | programs in lucid emacs?

   Big colored capital letters sounds really unappealing.  Better to
   put them in a small font, which will simulate the easy to read
   style of lower case keywords.

   (Simulated ergonomics.  Cool!)

It depends, if they are not appealing to you, you can use a lighter
shade of gray for keywords.

I agree though: an editor that quickly changed the keywords to
lowercase (perhaps bold lowercase) upon loading would be cool. Kind of
like good old THINK Pascal.

-- Farshad
--
Farshad Nayeri
nayeri@gte.com


======================================================================= 3 ===
Date:    1 Apr 1995 12:34:08 -0500
From:    fdrake@csgrad.cs.vt.edu (Fred L. Drake Jr.)
Subject: m3rpc package


  I'm looking to build the RPC package for RPC which Xerox
contributed.  I'm using a new installation of M3 3.5.2 on an Alpha
machine running OSF/1.  The installation ran fine so long as we had
disk space left.
  The difficulty we've come across is that the m3 compiler doesn't
seem to know what machine type we're running on, even though it worked
while building the various libraries we've installed.  Is there an
option to specify the target machine, or some way to use m3build with
the Xerox RPC package (currently, it uses make).
  Any help would be appreciated; please e-mail or post.  Thanks!

  -Fred

--
http://csgrad.cs.vt.edu/~fdrake/


======================================================================= 4 ===
Date:    Sat, 01 Apr 95 16:20:19 -0800
From:    mhb@pa.dec.com ("Marc H. Brown")
Subject: Re: Quake/m3build question -- installing resources


If you don't want m3build linked into your file, don't use m3bundle 
and don't use Rsrc; just use FileRd and Pathname. 

However, Rsrc is probably what you want: you can set a resource path 
containing environment variables and bundles. To read from the file 
system rather than the linked bundle, do two things: 

  1) be sure that the env var is before the bundle when you
     call Rsrc.BuildPath.
   
  2) set the env var to the directory containing the file

Just unset the env var when you want the file to come from the bundle 
rather than from the file system. 

Bundle and m3bundle are documented in SRC #113 (Some Useful M3 Interface). 
Unfortuntaely, Rsrc isn't documented there, however.




======================================================================= 5 ===
Date:    1 Apr 1995 19:14:35 GMT
From:    norman@flaubert.bellcore.com (Norman Ramsey)
Subject: Re: help wanted converting code from m3 v2.11 to v3.x

In article <DAGENAIS.95Mar30084529@notung.vlsi.polymtl.ca>,
Michel Dagenais <dagenais@notung.vlsi.polymtl.ca> wrote:
>   Does anybody know how to copy a heap object in m3 v3.x?
>
>Well, you can Pickle in and out of a TEXT or Pipe.

That copies not only the object but everything linked to it,
which is not quite what I'm after.  Bill's procedure for a ``shallow''
copy does the job.

Norman


======================================================================= 6 ===
Date:    2 Apr 1995 00:52:37 GMT
From:    linus@step.polymtl.ca (linus)
Subject: Re: need font-lock support for modula3 mode in lemacs

Farshad Nayeri (nayeri@gte.com) wrote:
: In article <SCHWARTZ.95Apr1003344@galapagos.cse.psu.edu> schwartz@galapagos.c
se.psu.edu (Scott Schwartz) writes:

:    umesh@fugue.lcs.mit.edu (Umesh Maheshwari) writes:
:    | Does anyone have a nice "modula3-font-lock-keywords" to color modula-3
:    | programs in lucid emacs?

:    Big colored capital letters sounds really unappealing.  Better to
:    put them in a small font, which will simulate the easy to read
:    style of lower case keywords.


First of all, CAP-LETERS-KEYWORDS really SUCKS !!!!!!!!!!!!!!!!!!!
It's the worst thing in M3 .....

;;;-------------------------------------------------------------------
(defvar modula-3-font-lock-keywords
  '(("^[ \t]*PROCEDURE[ \t]+\\([A-Za-z1-9_]+\\)" 1 font-lock-function-name-face
)
    ("^[ \t]*\\([A-Za-z1-9_]+\\)[ \t]+=[A-Za-z0-9_\. \t]*\\(OBJECT\\|RECORD\\)"
 1 font-lock-function-name-face)
    ("^[ \t]*\\([A-Za-z1-9_]+\\)[ \t]+\<\:" 1 font-lock-function-name-face)
    ("^\\(VAR\\|TYPE\\|REVEAL\\|CONST\\)" 1 font-lock-keyword-face)
    ("IMPORT\\|EXPORTS\\|GENERIC\\|INTERFACE\\|MODULE" . font-lock-keyword-face
)
    ("\\(RAISES\\|RAISE\\)\\|EXIT\\|RETURN" . font-lock-keyword-face))
  "m3 font-lock-kw")


----------------------------
LD

:    (Simulated ergonomics.  Cool!)

: It depends, if they are not appealing to you, you can use a lighter
: shade of gray for keywords.

: I agree though: an editor that quickly changed the keywords to
: lowercase (perhaps bold lowercase) upon loading would be cool. Kind of
: like good old THINK Pascal.

: -- Farshad
: --
: Farshad Nayeri
: nayeri@gte.com


======================================================================= 7 ===
Date:    2 Apr 1995 04:34:19 GMT
From:    norman@flaubert.bellcore.com (Norman Ramsey)
Subject: Q: What is the inverse of m3ship?


Is there an operation that reverse the effect of m3ship?
That is, something that removes all teh files originally created by
m3ship?  I want to `start over with a clean slate' to test an
installation procedure...

While I'm at it, does m3ship offer any protection against name
collisions (e.g., two people decide that `foo' would be a dandy name
for a {package, binary, other})?  If not, does it have more
discriminating friends?

Norman
--
Norman Ramsey
norman@bellcore.com


======================================================================= 8 ===
Date:    Sun, 2 Apr 1995 01:57:06 GMT
From:    kendall@spark.mv.com (Sam Kendall)
Subject: Re: Opinions on M3->C interface "consistency"

bm@shadow.cs.columbia.edu (Blair MacIntyre) writes:

> In making an interface to a C library (OpenGL, in particular), there
> is a tradeoff between "consistency" with the original C
> constant/variable names and consistency with the way typical .i3 files
> are written, as illustrated here:
> 
> GL.h:
> 
> #define GL_ACCUM 	0x0100
> 
> GL.i3:
> 
> CONST GL_ACCUM: INTEGER = 16_0100;
> 
> But, then to reference the constants, we write GL.GL_ACCUM, which is
> long (writing GL.ACCUM would be nicer, I'd think).

Yes, the problem with redundant prefixes is particularly bad when
mapping C enumerators -- you can get things like
`regex.reg_errcode_t.REG_ERPAREN'.

Going with the consistent style but making use of FROM IMPORT in client
code can be a good compromise.  Ideally, I'd keep the mapping from the
M3 interface to the corresponding C simple, even if cumbersome to use,
but try to build a safe M3 interface on top of that "raw", unsafe M3
interface.

---
Sam Kendall



======================================================================= 9 ===
Date:    2 Apr 1995 04:22:01 GMT
From:    norman@flaubert.bellcore.com (Norman Ramsey)
Subject: ANSWER: Quake/m3build question -- installing resources

(Following up my own post.)

In article <D6BpyM.76@walter.bellcore.com>,
Norman Ramsey <norman@flaubert.bellcore.com> wrote:
>I'd like to make ``resources'' (arbitrary binary files) available in a
>standard place for an application that needs them.  (A location
>analogous to /proj/pkg/foo-rsrc/src would be just fine.)
>Unfortunately, I don't see any way to do this with m3build and quake
>(I have version 3.3).  Note well that I do *not* want to use m3bundle
>to turn the resources into a module; I expect the resources to change
>more rapidly than the program that uses them, so I want to get them
>out of the file system dynamically.

OK, here's some quake code to do the installation.  I wrote some even
more frightening code to create an interface that points to the
appropriate subdirectory of PKG_USE (modelled on build_generic_intf).

BTW I discovered if a packages calls neither program() nor library(),
it's not much use unless it calls something like this:

  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  %
  %     this is what's needed to export things properly when we 
  %     don't build a program or a library
  
  proc Source_Package() is
    gen_m3exports("bogus bogus")
    install_derived (M3EXPORTS)
    install_sources()
  end

So far the only such packages I've written are the ones exporting
quake code or `resources' :-)

Norman

here is resource.tmpl

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% installed resources -- provide for files that should be installed
% with the package, even if they aren't part of a program
%
%
%  dynamic_resource(X)		installs X in pkg/NAME/src/X
%  derived_dynamic_resource(X)	installs X in pkg/NAME/BUILD/X
%
% The derived stuff hasn't been tested.


% implementation means using the quake `hooks' provided.

DYNAMIC_RESOURCES = {}	  % units just like the standard ones


% add hooks for installation by m3ship

readonly resource_install_units_hooks = install_units_hooks

proc install_units_hooks(install_impls)	is
  local x = resource_install_units_hooks(install_impls)
  return [x, DYNAMIC_RESOURCES]
end


% add hooks for lookup by m3where

readonly resource_where_units_hooks = where_units_hooks

proc where_units_hooks()	is
  local x = resource_where_units_hooks()
  return [x, DYNAMIC_RESOURCES]
end


% add hooks for writing into M3EXPORTS

readonly resource_map_hooks = gen_map_hooks

proc gen_map_hooks() is
  gen_unit_map(DYNAMIC_RESOURCES, "dynamic_resource")
end

proc _map_add_dynamic_resource(unit, pkg, subdir, visibility) is
  DYNAMIC_RESOURCES{unit} = [Location(pkg, subdir), visibility, IMPORTED]
end


%%%% naming the source is simplicity itself

proc dynamic_resource(x) is
  DYNAMIC_RESOURCES{x} = _new_unit(VISIBLE)
end

%%%% dealing with deriveds requires none of this goo...

proc derived_dynamic_resource(x) is
  install_derived(x)
  deriveds(x, no_extension)
end



======================================================================= 10 ===
Date:    01 Apr 1995 23:24:49 GMT
From:    umesh@note.lcs.mit.edu (Umesh Maheshwari)
Subject: enigmatic smuggling


I ran into a rather unexpected semantics of IMPORT/EXPORT (it does not seem
to be documented.) I wasted a lot of time to figure out what must be
happening. I would appreciate your views on the problem.

Here is the essence of the condition when the problem arises:
    1) interface X declares an opaque type T
    2) module Y reveals X.T
    3) interface X and module Y are used to form a library, say, z

    4) Some other module, Main, imports X 
       (the package containg Main imports the library z).

In building main, the compiler complains that X.T is not revealed.
I have pasted the simplified source files and m3makefiles below:

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

file z/src/m3makefile

    import(libm3)
    Interface(X)
    Module(Y)
    Library(z)

file z/src/X.i3

    INTERFACE X;

    TYPE 
      T <: ROOT;
    END X.

file z/src/Y.i3

    INTERFACE Y;
    END Y.

file z/src/Y.m3

    MODULE Y;

    IMPORT X;

    REVEAL X.T = ROOT BRANDED OBJECT
      i: INTEGER;
    END;

    BEGIN
    END Y.

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

file main/src/m3makefile

     import(libm3)
     override(z, "../..")
     import(z)
     implementation(Main)
     program(main)

file main/src/Main.m3

    MODULE Main;

    IMPORT X;

    BEGIN
    END Main.


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

The library "z" builds successfully.
But m3builds gives an error in building main:

new "Main.mo" -> linking main
opaque type never revealed: X.T (_tb81ca1e6)
  defined in X.i3

The error can be rid of by either of the following:

 1) Importing Y (besides  X) in Main.m3.
    This is unexpected because the interface Y does not contain anything.
 2) Exporting X in Y.m3
    This is unexpected because, according to the reference manual by
    Nelson, the only effect of "EXPORTS X" would be to provide bodies of
    procedures declared in X.

    The above two points indicate that the revelation of types is exported
    by a module just as it would export procedures. This is not
    documented.

  3) Main.m3 is put together with the sources of library z

    import(libm3)
    Interface(X)
    Module(Y)
    implementation(Main)
    program(main)

    It is unexpected that separating the sources into libraries with all
    interfaces visible should effect the linkability of the program.



======================================================================= 11 ===
Date:    2 Apr 95 10:00:53
From:    nayeri@gte.com (Farshad Nayeri)
Subject: Re: Opinions on M3->C interface "consistency"

In article <KENDALL.95Apr1205706@spark.mv.com> kendall@spark.mv.com (Sam Kendal
l) writes:

   bm@shadow.cs.columbia.edu (Blair MacIntyre) writes:

   > In making an interface to a C library (OpenGL, in particular), there
   > is a tradeoff between "consistency" with the original C
   > constant/variable names and consistency with the way typical .i3 files
   > are written, as illustrated here:
   > 
   > GL.h:
   > 
   > #define GL_ACCUM 	0x0100
   > 
   > GL.i3:
   > 
   > CONST GL_ACCUM: INTEGER = 16_0100;
   > 
   > But, then to reference the constants, we write GL.GL_ACCUM, which is
   > long (writing GL.ACCUM would be nicer, I'd think).

   Yes, the problem with redundant prefixes is particularly bad when
   mapping C enumerators -- you can get things like
   `regex.reg_errcode_t.REG_ERPAREN'.

   Going with the consistent style but making use of FROM IMPORT in client
   code can be a good compromise.  Ideally, I'd keep the mapping from the
   M3 interface to the corresponding C simple, even if cumbersome to use,
   but try to build a safe M3 interface on top of that "raw", unsafe M3
   interface.

I tend to agree with Sam. If you are not satisfied with that answer,
however, here are some other ideas:

- Generate the safe M3 interface and corresponding module that Sam
  mentioned in your tool to take the grunt work out of doing the safe
  wrapper. This interface can include all of the safe portions of the
  original interface, and perhaps some generated utilities for dealing
  with safe handles to unsafe data.

- As for stripping, you can change the rule to: only strip the prefix
  when the resulting identifier is valid in the current context.  This
  will make for an easy rule for "blind" naming of identifiers.

- More messy is changing the documentation: nroff, TeX, and PostScript
  and comments in C header files files should not be that hard to
  scan. You can actually change the documentation! I don't think it is
  a great way to go, but it is certainly an alternative.

- Trivial points: Don't forget about casing and underscores (gl, GL,
  GL_) Also you may want to name the unsafe interface UGL or CGL so
  that there can be a safe interface built on top of it called GL.

Overall, if you want to follow "the Modula-3 philosophy" of making
unsafe practices harder, you may want to leave the identifiers the
same as in a C program. Unfortunately this aspect of M3 philosophy
does not sit well with "wanting to make integration easier".

-- Farshad
--
Farshad Nayeri
nayeri@gte.com


======================================================================= 12 ===
Date:    3 Apr 1995 12:23:09 GMT
From:    Quentin Stafford-Fraser <fraser@europarc.xerox.com>
Subject: Re: m3rpc package

 
fdrake@csgrad.cs.vt.edu (Fred L. Drake Jr.) wrote: 
 
> Is there ... some way to use m3build with 
>the Xerox RPC package (currently, it uses make). 
 
I have a version which works, though I haven't tested it very much, or   
indeed used it much since 3.3.  It does a little hack in quake to produce   
m3rpcgen, which is a C-only program. 
 
You can get the package from   
http://www.cl.cam.ac.uk/users/qs101/m3rpc.tar.gz. 
 
--  
 --------------------------------------------------------------------- 
                       Quentin Stafford-Fraser 
           http://pelican.cl.cam.ac.uk/people/qs101/me.html 
 --------------------------------------------------------------------- 




======================================================================= 13 ===
Date:    3 Apr 1995 14:10:36 -0400
From:    fdrake@csgrad.cs.vt.edu (Fred L. Drake Jr.)
Subject: Re: m3rpc package

In article <3lopbd$391@news.parc.xerox.com>,
Quentin Stafford-Fraser  <fraser@europarc.xerox.com> wrote:
>I have a version which works, though I haven't tested it very much, or   
>indeed used it much since 3.3.  It does a little hack in quake to produce   
>m3rpcgen, which is a C-only program. 
> 
>You can get the package from   
>http://www.cl.cam.ac.uk/users/qs101/m3rpc.tar.gz. 


Quentin,
  Thanks for the pointer, and the effort!  I'll take a look at what
you have there.  Since my post I brought m3rpcgen to life on the Alpha
(that much was working fine on a Linux box); I think the problem was
in the 32/64 bit translation.  A serious lack of prototypes can be a
problem when the platforms are changing so rapidly!
  Again, thanks, and I'll let you & others know here if/when it's all
working under 3.5.2.


  -Fred

--
http://csgrad.cs.vt.edu/~fdrake/


======================================================================= 14 ===
Date:    3 Apr 95 09:51:15
From:    dagenais@notung.vlsi.polymtl.ca (Michel Dagenais)
Subject: Modula-3 expected developments


With the increasing activity on comp.lang.modula3, it would be
interesting to discuss where the Modula-3 environment may go in the
short and medium term. It helps put things in perspective and coordinate
the efforts. Obviously most of the efforts come from DEC SRC, and are
well coordinated there, but the outside SRC community is rapidly expanding
and maturing.

A Modula-3 users meeting will probably be held at the Usenix COOTS
(conference on OO technologies) in Monterey (June 26-29).

The m3build/quake/m3/m3cg suite of programs is being melted into an
extremely fast compile server which caches pre compiled interfaces
and library information. The very fast integrated code generator
will need to be adapted to each platform architecture.

M3gdb is quickly maturing (on other that DS3100 platforms) and is now
quite usable although there are still a number of minor problems to
fix.

I had students this term build prototypes of an integrated development
environment (file chooser, editor and links to compiler, debugger
and performance analysis tools). Something will eventually come out
of this.

The user interface development environment is excellent. The newly released
shared board graphics editor could form the basis of a structured graphics
library (a la Unidraw). With a couple of additions like a table VBT,
rotated texts and even an HTML viewer, this would be real nice.

Stable persistent objects were recently released. Hopefully this will
evolve towards an OO database toolbox; this with FormsVBT, network
objects and Obliq would be the right tool for a lot of interesting 
applications.

I am exploring ways of automating the submission of contributed Modula-3
items (packages, binaries, FAQ items) with immediate linking into the
documentation Web. In parallel, work is underway to generate linear
printable versions of documentation Web subgraphs on the fly.
This scheme will fit well with M3browser.

In summary, all the pieces are getting in place at an increasing pace,
in large part because the SRC researchers have experimented with all these
ideas before.
--

Prof. Michel Dagenais        http://www.vlsi.polymtl.ca/dagenais/home/home.html
Dept of EE and Computer Eng.        dagenais@vlsi.polymtl.ca
Ecole Polytechnique de Montreal     tel: (514) 340-4029



======================================================================= 15 ===
Date:    3 Apr 95 08:48:18
From:    dagenais@notung.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: what is modula 3


    i  often writing programs in an Modula 2 Environment (DOs)
    can you help me what is modula 3 ?

Modula-3 resembles Modula-2 but has objects, threads, garbage collection,
generics and exceptions. A good starting point is reading the Modula-3
FAQ available from ftp.vlsi.polymtl.ca:pub/m3/m3-faq.txt.
--

Prof. Michel Dagenais        http://www.vlsi.polymtl.ca/dagenais/home/home.html
Dept of EE and Computer Eng.        dagenais@vlsi.polymtl.ca
Ecole Polytechnique de Montreal     tel: (514) 340-4029



======================================================================= 16 ===
Date:    3 Apr 1995 18:31:33 GMT
From:    ken.seefried@6856.404259.bst.bst.bellsouth.sprint.com (K.J. Seefried I
II)
Subject: Modula-3 on NT


I'm about to start looking at the Modula-3 compiler for NT.  Since
DEC is big on NT, I'm curious as to how much support the NT port is
going to recieve.  Will it be equal to the fine support the Unix
variants seem to be recieving?

-- 
  K.J. Seefried III
  ken.seefried@bridge.bst.bls.com
  Compaid Consulting Services @ BellSouth Telecommunications



======================================================================= 17 ===
Date:    Mon, 03 Apr 95 17:28:38 -0700
From:    heydon@pa.dec.com
Subject: Re: enigmatic smuggling

Umesh,

The behaviors you observed are consistent with the language
definition, which says (section 2.5):

  A "program" is a collection of modules and interfaces that contains
  every interface imported or exported by any of its modules or
  interfaces, and in which no procedure, module, or interface is
  multiply defined.

Hence, a program is a collection of "units" (my generic term for an
interface or a module) that is closed under IMPORTs and EXPORTS.
However, the language does not say how the SRC compiler constructs
this closed set from the units listed in m3makefiles. These rules do
not seem to be documented anywhere, so here they are for posterity, as
explained to me by Bill Kalsow:

  * First, the compiler only includes in the build those units that
    are deemed reachable from a certain set of "roots" in a directed
    graph defined on the units. An edge exists in this graph from unit
    A to unit B if either: 1) A IMPORTs B, or 2) B EXPORTS A.
  
  * Second, the set of search "roots" (or starting points of the
    traversal) is the set of units declared in the "main" m3makefile.

Together, these two rules explain all the behaviors you witnessed.
First, consider the case that failed:

> Here is the essence of the condition when the problem arises:
>     1) interface X declares an opaque type T
>     2) module Y reveals X.T
>     3) interface X and module Y are used to form a library, say, z
>
>     4) Some other module, Main, imports X 
>        (the package containing Main imports the library z).
>
> In building main, the compiler complains that X.T is not revealed.

Since "Main.m3" only imports "X", and since neither "X" imports "Y"
nor "Y" exports "X", here is the graph formed by the first rule:

       Main.m3 ---> X.i3 <--- Y.m3 <--- Y.i3
       ~~~~~~~  I          I         E

(I've labeled the edges with "I" and "E" based on whether they are
included due to an "IMPORT" or "EXPORTS" relation, and I've underlined
the root.) In this graph, the only root node is "Main.m3", and only
"X.i3" is reachable from it, so the compiler includes neither "Y.i3"
nor "Y.m3" in the build, and hence complains that "X.T" is not
revealed.

Now, consider the three cases you proposed to fix the problem:

>  1) Importing Y (besides  X) in Main.m3.

Adding this IMPORT changes the graph, and makes "Y.m3" reachable
though "Y.i3":

                           I
	   /------------------------------\
	   |                              |
	   |                              V
       Main.m3 ---> X.i3 <--- Y.m3 <--- Y.i3
       ~~~~~~~  I          I         E

Hence, "Y.m3" gets included in the build, and the compiler finds a
concrete revelation for "X.T".

>  2) Exporting X in Y.m3

This adds an "EXPORTS" edge from "X.i3" to "Y.m3":

                           E
       Main.m3 ---> X.i3 <===> Y.m3 <--- Y.i3
       ~~~~~~~  I          I          E

Now, "Y.m3" has again become reachable from the root "Main.m3" through
"X.i3".

>  3) Main.m3 is put together with the sources of library z
>
>    import(libm3)
>    Interface(X)
>    Module(Y)
>    implementation(Main)
>    program(main)

This does not change the original graph, but it does change the set of
roots:

       Main.m3 ---> X.i3 <--- Y.m3 <--- Y.i3
       ~~~~~~~  I   ~~~~   I  ~~~~   E  ~~~~

In this case, all of the units are roots, so they are all included in
the build. Hence, the concrete revelation for "X.T" contained in
"Y.m3" is seen by the compiler.

I hope I've cleared things up, but let me know if you still have 
any questions. 

- Allan

--------------------------------------------------------------------
Allan Heydon                           Digital Equipment Corporation
heydon@pa.dec.com                      Systems Research Center
(415) 853-2142                         130 Lytton Avenue
(415) 853-2104 (FAX)                   Palo Alto, CA 94301


======================================================================= 18 ===
Date:    4 Apr 1995 08:01:02 GMT
From:    heinze@i41s5.ira.uka.de (Ernst A. Heinz)
Subject: Re: Modula-3 expected developments

Adding to all the efforts mentioned by Michel, I like to inform the Modula-3
community that the integration of our general-purpose parallel programming
model GPPM into Modula-3 has made good progress, too. Due to limited time
and personnel we cannot proceed as fast as we wish, but we have already
caught up with SRC-M3 release 3.5.2 and hope to release a first Modula-3*
version during this year.

For the interested, I include more information on GPPM and Modula-3* below.

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

GPPM is remarkably compact yet very powerful, including only high-level,
machine-independent abstractions. It demands the explicit formulation of
parallel computations in order to exploit parallelism and offers unified
control+data parallelism by means of general FORALLs, structured pipeline
parallelism by means of typed pipelines, and general task parallelism by
means of FORK/JOIN/LOCK primitives. These different kinds of parallelism
may freely be nested with each other and the remaining control constructs,
e.g. branches, loops, or subroutines.

Modula-3* does not only orthogonally embed GPPM's different kinds of
parallelism with each other but also with the full Modula-3 language,
including such sophisticated concepts like exception handling, garbage
collection, generics, inheritance, and objects. Hence, it supports all
Modula-3 abstraction mechanisms for parallel programming as well.

GPPM's full integration into Modula-3 requires only three new language
constructs, namely FORALL, NOSYNC, and PIPE statements. The additional
syntax rules for Modula-3* with respect to the original Modula-3 grammar
are listed listed below.

ForallSt ::= FORALL Id ":" "[" Range "]"
             (DO | NOSYNC) S END.
NoSyncSt ::= NOSYNC S END.
PipeSt   ::= PIPE [CallSt] {"|" CallSt} END
           | PIPE [IN | OUT] Expr
           | PIPE EXIT.
Stmt     ::= ForallSt | NoSyncSt | PipeSt.
Range    ::= Expr ".." Expr [BY Expr].

Please note that earlier Modula-3* publications contain other definitions
of FORALL range syntax and do not support pipeline parallelism, thus not
completely providing GPPM.

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

=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)  |                   |
+--------------------------------------------------------+-------------------+

"It has recently been found out that research causes cancer in rats!"


======================================================================= 19 ===
Date:    04 Apr 1995 01:35:45 GMT
From:    bm@age.cs.columbia.edu (Blair MacIntyre)
Subject: Re: Modula-3 expected developments

>>>>> On 3 Apr 95 09:51:15, dagenais@notung.vlsi.polymtl.ca (Michel
>>>>> Dagenais) said:

Michel> With the increasing activity on comp.lang.modula3, it would be
Michel> interesting to discuss where the Modula-3 environment may go
Michel> in the short and medium term. It helps put things in
Michel> perspective and coordinate the efforts. Obviously most of the
Michel> efforts come from DEC SRC, and are well coordinated there, but
Michel> the outside SRC community is rapidly expanding and maturing.

Well, I'm currently working on a simple form of "replicated objects"
(for lack of a better term).  My basic need is to have the ability to
have an object replicated across many machines, have changes propogate
(as quickly as possible in some cases), have them be somewhat
transparent to the user (as network objects are), and have them
integrated with Obliq.  There are some other nitpicky requirements,
but that's the gist of it right now.

If anyone else has worked, or is working on, or is just interested in
talking about this, let me know.  This seems like a database problem
(of which I'm not an expert), but I need it for the augmented reality
system I'm building.
--
Blair MacIntyre (bm@cs.columbia.edu), Graduate Student (Graphics and UI Lab)

smail: Dept. of Computer Science, 450 Computer Science Building, 500 W 120 St.
       Columbia University, New York, NY 10027


======================================================================= 20 ===
Date:    4 Apr 1995 09:45:17 -0500
From:    hosking@cs.purdue.edu (Tony Hosking)
Subject: Re: Solaris 2.3: -lDYNAMIC_LINKING_AFTER_THIS

>>>>> "Blair" == Blair MacIntyre <bm@shadow.cs.columbia.edu> writes:

>>>>> On 30 Mar 1995 16:11:46 -0500, hosking@cs.purdue.edu (Tony
>>>>> Hosking) said:

    Guido> Should this -lDYNAMIC_LINKING_AFTER_THIS be a special option to
    Guido> gcc.  Well, I installed gcc 2.6.3 hoping this will solve the
    Guido> problem, but it doesn't. I installed it using Sun's as and ld.

    Tony> Just delete the line:

    Tony> boot_import ("-lDYNAMIC_LINKING_AFTER_THIS")

    Tony> from the file m3/SOLgnu/make.boot in boot-SOLgnu and you will be
    Tony> away and laughing.

    Blair> Well, laughing might not be the right word.  You cannot statically
    Blair> link an m3 binary on solaris without this option and without using
    Blair> the m3-gcc script (or something like it).

    Blair> If you remove it, remove all "build_standalone()" commands from
    Blair> your m3makefiles.  -- Blair MacIntyre (bm@cs.columbia.edu),
    Blair> Graduate Student (Graphics and UI Lab)

If you had read my message more closely, this is only in the make.boot file,
not the SOLgnu configuration file.  There is no real need for make.boot to
link the compiler statically.  The build_standalone stuff will still work just
fine for the other packages in the distribution.

Now I am laughing!
-- 
Tony Hosking			|	Voice:	(317) 494-6001
Department of Computer Sciences	|	Fax:	(317) 494-0739
Purdue University		|	Email:	hosking@cs.purdue.edu
West Lafayette, IN 47907URL:	|	http://www.cs.purdue.edu/people/hosking


======================================================================= 21 ===
Date:    4 Apr 1995 06:20:43 GMT
From:    dhwang@ic.sunysb.edu (David Hwang)
Subject: FileStream.i3


I've been having trouble invoking FileStream.i3 under M3PC.  The compiler just
tell me that it can't find such interface.  FileStream.i3 is the first long
filename(more than 8 letter in prefix) I use for M3PC, is it because of the
long filename?  I've checked names.map and everthing mapped fine.  Help!

-- 
(-_-;)
SF - DH


======================================================================= 22 ===
Date:    4 Apr 1995 18:55:13 GMT
From:    davidf@cais2.cais.com (David R Fruehwald)
Subject: Modula-3 on OS/2

Should one want to dabble a bit with Modula-3 is there a compiler for OS/2?


======================================================================= 23 ===
Date:    Wed, 05 Apr 1995 9:59:34 METDST
From:    rudy@cs.rug.nl
Subject: Language Definition (equal types)

At this moment I find Modula-3 one of the best programming languages.
Working with Modula-3 I still find minor points where the language
(definition) could be improved. Therefore I will propose some minor changes
to the language definition. I hope to initiate a fruitful discussion about
the language definition. I will collect the reactions and write a final
report. 

I have already posted (newsgroup: comp.lang.modula3) the final report on
readonly variables. Due to an insufficient number of reactions, I can not
(yet) write final reports on the subjects: "addresses" and "overrides"

Messages sent to m3@src.dec.com are automatically forwarded to the newsgroup
comp.lang.modula3. Reactions can also be sent to me personally:
rudy@cs.rug.nl

Example
=======

When are two types equal?  

See the Language report section 1.3: Modula-3 uses structural equivalence,
instead of the name equivalence of Modula-2.  Two types are the same if
their definitions become the same when expanded; that is, when all constant
expressions are replaced by their values and all type names are replaced by
their definitions.

Application of this rule stricktly leads to the following erroneous program:

MODULE Main;

VAR x:RECORD p:=0.3 END;
    y:RECORD p:=0.4 END;
    z:RECORD p:REAL END;

BEGIN
  x:=y; (* error: types are not assignable *)
END Main.

(Bill Kalsow:) Under the strictest intrepretation, the default values of
fields are part of the type's definition.  The Modula-3 designers generally
agree that this is a bug.  It probably would have been better to ignore the
default values.  Trying to decide whether two types with floating-point
expressions for their defaults are equal makes this bug painfully obvious.

>From my point of view; structural equivalence and initialization are
different properties. So "x" and "y" are structural equivalent, but posses
different initializations.  So this program should correct. Even a subtype
relations does not make sense. We could consider the types of "x" and "y" to
be subtypes of "z". A subtype relation suggests restricted assignability
which is not the case here. The variables "x", "y" and "z" should be fully
assignable amongst eachother. So the language definition must be changed in
the sense that the types of "x", "y" and "z" are equal types with different
initializations. As a consequence, the initialisation should not be
considered as a part of the type definition.

In case of objects this new definition leads to problems. The question is now
more subtile.

TYPE O1 = OBJECT METHODS p():=P1 END;
     O2 = OBJECT METHODS p():=P2 END;

These objects differ in their method suite. The essential question to
determine wether these two types are different is: is the pointer to the
method suite a constant or a hidden (for the user) initializez readonly
variable?

In the first case, the pointer is a constant and the types are structural
different. You have a similar situation in case of array declaration, the
index range is also described by two constants which are (if expanded) part
of the type definition. The constant pointer can at compile time be replaced
by the actual value. This keads sometimes to slightly more efficient
implementations.

In the second case, if the number of declared methods and their declarations
are equal (which is the case in this example) the method suites of both
object types are structurally equal, so they are of the same type. If also
the number of fields and their declarations are equal, both object types are
equal. E.g. these types only differ in their initialization. Now we consider
the method suite as a hidden initialized readonly variable, to be
initialized by the default method initializations and the overrides.

I have a slight preference for the second interpretation, but at this moment
I can not fully oversee all consequences. I believe that this choise should
be made by the compiler builders and not by the users. Notice that the
second interpretation reduces the number of different types tremendously!

With the present interpretation or the first proposed interpretation

  NEW(O1, p:=P1)

produces a new anonymous type with a different typecode. With the second
interpretation the type of the result is as expected O1. This means that
with the second interpretation the concept of anonymous types disappears
from the language definitions. Personally I believe I is not correct that
NEW can construct new types! This should only be a task to be performed by
type constructors.

Proposal 7: structural equivalence
==================================

Modula-3 uses structural equivalence, instead of the name equivalence of
Modula-2.  Two types are the same if their definitions become the same when
expanded; that is, when all constant expressions refering to packing
or the lower- and upperbound of subrange types are replaced by their values
and all type names are replaced by their definitions. Constant expressions
for field initialization of records and default result or parameters for
procedures or are not considered.

Syntax
======

No changes



======================================================================= 24 ===
Date:    Tue, 4 Apr 1995 17:26:10 GMT
From:    shang@corp.mot.com (David L. Shang)
Subject: Re: Static vs Dynamic Typing: Effects on Productivity?

In article <3lcilu$4sa@hermes.dna.mci.com> 7231780@mcimail.com writes:
> In <3536sa$5se@cantaloupe.srv.cs.cmu.edu>, rwh@cs.cmu.edu (Robert Harper)  
writes:
> >For example, one cannot tell
> >by the bit pattern whether the value in a variable represents a "set"
> >or a "time of day" or a "favorite color of the author of the program". 
> >Nor can one check at run-time properties of, say, functions that can be
> >enforced by a static type discipline.
> 
> In a dynamically typed system such as Smalltalk (or, untyped), I don't have  
to examine the bit pattern to determine the value.  The class lookup mechanism 
 
knows the value representation and invokes the class that will process the  
variable.  (polymorphism).  This increases programmer productivity factorially 
 
over statically typed compilers.
> 
> Therefore, the argument is flawed by the response "I, the programmer, do not 
 
care."  Also, dynamically typed languages also have "isKindOf" queries to  
determine type if they have to.
> 
> Your argument is flawed.

What is static typing, what is dynamic typing after all? 

Runtime type check or runtime type identification is not the watershed between 
 
dynamic typing and static typing. When type is a first-class object, one can  
always pass it as value and check it at runtime. As long as full type  
information is loaded into the runtime executable, one can always ask an object
  
the "IsKindOf" question, no mater the language is static or dynamic.

Dynamic typing: type is not a constant object (a dynamic object), i.e. the  
state of a type can be changed at runtime. One can add/delete/change attributes
  
associated to a type at runtime;
 
Static typing: type is a constant object (a static object), i.e. the state of a
  
type can not be changed at runtime. One can change the attributes associated to
  
a type once it is defined in the program;

Dynamic typing: subtypes can be created/deleted at runtime. The class  
hierachical graph is dynamic.

Dynamic typing: subtypes cannot be created/deleted at runtime. The class  
hierachical graph is static.

Is there any way that one can smooth the gap between static typing and dynamic 
 
typing? One of the major goals of the Cluster-2 programming language is to  
address this question. Classes can be "frozen" or "melt" among the dynamic
environment and the static environment freely.

David Shang







======================================================================= 25 ===
Date:    Wed, 5 Apr 1995 12:33:36 -0500
From:    douglm@rpi.edu (Mike Douglass)
Subject: Re: Modula-3 expected developments

So you know why I'm here:

I'm currently working on the development of a database system with leanings
towards bibliographic databases, hopefully for use in our library (at RPI).
The system consists of a database server, a Z39.50 server and some grungy
special purpose clients.

The system makes use of the following components:

secondary storage manager:
  manages page formatted (disk) storage. Provides page caching, atomic
updates, disk mirroring etc.

Interpreted scripting language:
  An extensible language which can be executed stand alone, in the server
or in the client(s). For example, Z39.50 functionality is provided by
calling routines defined in this language to carry out the required
searching and display functions.

The server itself consists of:
   the secondary storage manager,
   an object manager: provides retrieval/storage of objects using the Ss
manager,
                caching of objects, sharing of read only versions between
processes etc.
   transaction manager:
   index objects
   database objects
   A network interface, communicating with clients using network objects.

The Z39.50 server is implemented as a general purpose server, that is it
can provide Z39.50  access to any system that has enough functionality. The
server is provided with an object the methods of which are called to carry
out the desired functions.
Essentially the Z39.50 code is a subroutine to a main program which
interfaces to the database system.

The server has functioned with the above system and with the current online
catalog system running on the mainframe.

Along with all this is code to handle MARC formatted data and much else besides
.

The system as a whole has made it's first faltering steps. A small database
has been built and records displayed using a Z39.50 client. At the moment
I'm working on some extensions to allow me to build a duplicate of a known
subset of our online catalog.

The results can then be compared to provide some degree of confidence in
what we have.




======================================================================= 26 ===
Date:    5 Apr 1995 16:54:10 +0200
From:    laverman@cs.rug.nl (Bert Laverman)
Subject: Re: Modula-3 expected developments


I once had a group of two students work on a translation
of the scanner- and parser generators from the Modular
Pascal toolbox. The total ModPas set includes a compiler,
code generator generator, etc.
  The project did result in running generators, but the
generated code had problems, and at that time the HPPA
port was far from stable. We ran out of time, and I built
a parser/scanner set by hand for my own project. The ModPas
people however did agree to allowing the software to spread.
If anyone is interested in taking over the project, the
set includes a LALR and a LL parser generator, with of course
a scanner generator.
  Modular Pascal is an extension of Pascal that includes
exceptions and modules, be it without separate interfaces.
Porting from ModPas to Modula-3 is not too hard, a Pascal-to-m3
converter might speed up things a lot. (IF/WHILE syntax etc.)

Any takers are invited to react by email.

Bert Laverman
-- 
  ------------------------------------------------------------------
  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


======================================================================= 27 ===
Date:    Wed, 05 Apr 95 15:29:23 -0700
From:    heydon@pa.dec.com
Subject: Re: Finalization


Spencer Allain writes:

> Modula-3 has garbage collection, just like Eiffel, but I'm unsure
> how to release something like a network connection, a file, or a
> socket automatically when the object that contained that resource gets
> collected.
>
> I'm sure there must be some mechanism, but I don't recall seeing
> anything specifically about this.

The "WeakRef" interface is designed exactly for this purpose. The
first paragraph of the interface says:

  Most Modula-3 programs simply let the garbage collector deallocate
  storage automatically, but some programs need more control. For
  example, if a variable allocated in the traced heap contains a
  handle on a resource in the operating system or in some other
  address space, then when the variable is garbage-collected it may be
  important to deallocate the resource. The "WeakRef" interface
  provides this additional control.

"WeakRef" is part of the libm3core library; its source files are in
the package named "weakref".

- Allan


======================================================================= 28 ===
Date:    Wed, 05 Apr 1995 09:01:42 -0700
From:    bruce@newton.apple.com (Bruce Thompson)
Subject: Re: enigmatic smuggling

In article <UMESH.95Apr1162449@note.lcs.mit.edu>, umesh@note.lcs.mit.edu
(Umesh Maheshwari) wrote:

> I ran into a rather unexpected semantics of IMPORT/EXPORT (it does not seem
> to be documented.) I wasted a lot of time to figure out what must be
> happening. I would appreciate your views on the problem.
> 
> Here is the essence of the condition when the problem arises:
>     1) interface X declares an opaque type T
>     2) module Y reveals X.T
>     3) interface X and module Y are used to form a library, say, z
> 
>     4) Some other module, Main, imports X 
>        (the package containg Main imports the library z).
> 
> In building main, the compiler complains that X.T is not revealed.
> I have pasted the simplified source files and m3makefiles below:
> 
> ======================================
> 
> file z/src/m3makefile
> 
>     import(libm3)
>     Interface(X)
>     Module(Y)
>     Library(z)
> 
> file z/src/X.i3
> 
>     INTERFACE X;
> 
>     TYPE 
>       T <: ROOT;
>     END X.
> 
> file z/src/Y.i3
> 
>     INTERFACE Y;
>     END Y.
> 
> file z/src/Y.m3
> 
>     MODULE Y;
              ^
               EXPORTS X;

> 
>     IMPORT X;
> 
>     REVEAL X.T = ROOT BRANDED OBJECT
>       i: INTEGER;
>     END;
> 
>     BEGIN
>     END Y.
> 

The syntax may be a bit off, but that's the idea. The problem is that in
the code that you've provided, no module in the library _implements_ the
interface X. The revelation on X.T is not connected with interface X
because Y has not been declared to implement interface X.

Simply changing Y to declare that it implements interface X will solve the
problem.

   Cheers,
   Bruce.

-- 
--------------------------------------------------------------------
Bruce Thompson                  | "Never put off till tomorrow what
PIE Developer Information Group |  you can comfortably put off till
Apple Computer Inc.             |  next week."
                                |    -- Unknown
Usual Disclaimers Apply         |


======================================================================= 29 ===
Date:    Wed, 5 Apr 1995 14:38:09 GMT
From:    spencer@ERA.COM (Spencer Allain)
Subject: Finalization


I have been following an interesting discussion in another newsgroup
(comp.lang.eiffel) concerning whether eiffel is able to release
an objects resources.  I have included a piece of it below:

>>One thing I haven't found is a way of finalizing objects: ie cleaning them
>>up when they are no longer needed (what C++ would call destructors).
>
>>I know Eiffel garbage collects objects, thereby freeing memory, but what
>>happens if the object should release other resources, like a network
>>connection, a display context, or whatever?
>
>You can redefine feature 'delete' which normally does nothing.  Have
>a look at the descendants of IO_MEDIUM (ISE base libraries), they redefine
>delete to close files, sockets, etc when the objects are garbage collected.  
>
>Delete is called by the garbage collector when an object is collected.

Modula-3 has garbage collection, just like Eiffel, but I'm unsure how to
release something like a network connection, a file, or a socket automatically 
when the object that contained that resource gets collected.

I'm sure there must be some mechanism, but I don't recall seeing anything
specifically about this.

Thanks in advance for any insight.

-Spencer Allain
Engineering Research Associates
Vienna, VA  22182


======================================================================= 30 ===
Date:    6 Apr 1995 06:38:59 GMT
From:    ssthind@flash.LakeheadU.Ca (Sonny Thind)
Subject: What is modula 3 used for?

I used modula 2 about 5-6 years ago but then kind of left it behind and 
have been using C now. I am wondering what kind of applications and uses 
modula 3 is being used for, maybe I should go back to it. 

Any information will be greatly appreciated.

______________________________________________________________________________
Sonny Thind                                      SSThind@flash.LakeheadU.ca


======================================================================= 31 ===
Date:    Thu, 6 Apr 1995 09:47:55 -0400
From:    gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS)
Subject: re: Modula-3 expected developments

Our group here at Sun Labs East is using Modula-3 to
support it's research in distributed systems in a 
variety of ways. We have developed a distributed transaction
manager and an object activation service for Network Objects.
I expect these will be made publically available in the 
not too distant future. We have also implemented a distributed 
event registration and notification service on top of Network
Objects. I am in the process of building a lightweight UDP-based
transport for network objects with the eventual goal of running
directly on top of a raw ATM network driver. If there is interest,
we may make the event service and our UDP-based network object's
transport available in the future.

--geoff

Geoff Wyant
Geoff.Wyant@east.sun.com
Sun Microsystems Laboratories

2 Elizabeth Drive
Chelmsford, Ma.
01824


======================================================================= 32 ===
Date:    6 Apr 1995 16:42:44 GMT
From:    ml@lptl.jussieu.fr (Mathieu LAFARGE p 72551)
Subject: Modula3 and Oberon2.

Keywords: 

Well. I had never heard about Modula-3 before.
How can it be compared to Oberon-2?
Both are sons of Modula-2,aren't they?


======================================================================= 33 ===
Date:    6 Apr 1995 20:46:54 GMT
From:    jim.anderson@cyberstore.ca (Jim Anderson)
Subject: comdex on cd-rom

CD-ROM of ALL COMDEX (This is the worlds largest computer trade show-ie all the
 newest and coolest in software and computer hardware)(Las Vegas, Nov.1994) bro
chures for $49.95 US (Money Order)
Scanned in at 200 DPI, line art with corresponding database.(Windows,DOS)
Mail money order and where you want your CD-ROM mailed to:

First National Data Bank 
Box 24008, Kelowna, V1Y 9P9, BC, Canada

Please allow 2 weeks for delivery.



======================================================================= 34 ===
Date:    Thu, 6 Apr 1995 19:06:56 GMT
From:    spencer@ERA.COM (Spencer Allain)
Subject: translation listing exist?


I was wondering if someplace there exists a repository of Examples that show
how to implement a concept particular to another language in Modula-3.  I just
thought of asking this question because of another question I just recently
asked concerning finalization.

I was envisioning some type of document that would cite common questions for
someone who wants to start using Modula-3, and has knowledge of some other O-O
capable language.  I can see questions like: 
  Where are the constructors and destructors?????
  What do I use for a string????
  I cross-include header files in C++ source files, so I can have two objects
     point at each other - can, and how do I do that with Modula-3?
  In C++ I grab command line arguments from main(argc, argv**), what's the
     best way to do this in Modula-3?
  I know what a template looks like, now what would a corresponding GENERIC
     module look like?
  Good persistent storage in C++ is practically non-existant, is there some
     easy way to do this in Modula-3.  (Is there some way to do this so
     that the file is human readable and platform independent?)
  How are cycles of objects pointing to each other deleted from memory?
     (This is a problem regardless of whether you have garbage collection
      or do the collection manually)

  (Yes, I'm very familiar with C++ :)  (Not by choice though)

Documents like these would make it easier for people to transition to
Modula-3, because it would give them a way to translate their thought
patterns.  Many people are hesitant to change languages because they already
know how to do something "neat" with their current language and are afraid
that it won't be possible in another one, or that it would take too long to
figure out how to emulate their "cool" functionality.

I feel like I'm asking a lot of questions, but not contributing many answers
to this newsgroup :)  Hopefully, I'll have time to keep learning more about 
Modula-3, and then I'll be one of the friendly people who _answers_ questions.

Thanks for everyone's time and patience.

-Spencer Allain
Engineering Research Associates
Vienna, VA  22182


======================================================================= 35 ===
Date:    Fri, 7 Apr 95 09:17:23 GMT
From:    ohk@hal.nta.no (Ole-Hjalmar Kristensen TF.E/DELAB)
Subject: re: Modula-3 expected developments

In article <9504061347.AA08641@cloyd.East.Sun.COM>, gwyant@cloyd.East.Sun.COM (
Geoffrey Wyant - Sun Microsystems Labs BOS) writes:
|> Our group here at Sun Labs East is using Modula-3 to
|> support it's research in distributed systems in a 
|> variety of ways. We have developed a distributed transaction
|> manager and an object activation service for Network Objects.
|> I expect these will be made publically available in the 
|> not too distant future. We have also implemented a distributed 
|> event registration and notification service on top of Network
|> Objects. I am in the process of building a lightweight UDP-based
|> transport for network objects with the eventual goal of running
|> directly on top of a raw ATM network driver. If there is interest,
|> we may make the event service and our UDP-based network object's
|> transport available in the future.
|> 
|> --geoff
|> 
|> Geoff Wyant
|> Geoff.Wyant@east.sun.com
|> Sun Microsystems Laboratories
|> 
|> 2 Elizabeth Drive
|> Chelmsford, Ma.
|> 01824

Yes, a *lightweight* UDP on top of an ATM network would be great.
The group I am working in is using message passing on an ATM swith as part of a
parallell, highly fault tolerant soft real time RDBMS, and the depressing fact 
is
that most of the time used in message passing is consumed by Unix, not by the A
TM
switch. The net effect is that using an ATM
network is just slightly faster than using ethernet in terms of message round
trip times. The throughput is much better, of course. It seems that Unix refuse
s
to let the our process regain control instantly when a message arrives, but
instead waits for some time (several hundred microseconds), possibly in the hop
e
of catching more incoming messages.
(We use C++, but the problem would be the same in any language)
If you have any suggestions to how we can avoid what seems to be unnecessary
delay in the message passing, we would be very interested.
Btw, this phenomenon occurs both on SUN (SunOs 4.1.3) and HP platforms.

Ole-Hj. Kristensen


======================================================================= 36 ===
Date:    07 Apr 1995 17:51:03 GMT
From:    nayeri@gte.com (Farshad Nayeri)
Subject: Re: translation listing exist?


Spencer Allain said:

> I was wondering if someplace there exists a repository of Examples
> that show how to implement a concept particular to another language
> in Modula-3.  I just thought of asking this question because of
> another question I just recently asked concerning finalization.
>
> [...]
>
> Documents like these would make it easier for people to transition
> to Modula-3, because it would give them a way to translate their
> thought patterns.  Many people are hesitant to change languages
> because they already know how to do something "neat" with their
> current language and are afraid that it won't be possible in another
> one, or that it would take too long to figure out how to emulate
> their "cool" functionality.

Spencer,

A long time ago, I saw a promotional article on the net by Sam
Harbison which had answers to some of your questions. (I specifically
recall that the it addressed constructors and destructors to an
extent.)

Looking at my old mail, I found a reference to the document I was
talking about, but I am affraid I don't have a copy of it. The Pine
Creek catalog also included other information that is probably useful
to programmers today.

> pub/doc/m3forcpp.ps.Z  1-page (legal-size) brochure on M3 for C++ users
> pub/doc/m3forcpp.txt   (text version)

Perhaps Sam is willing to distribute some of the old Pine Creek
articles. (They may be outdated given the many improvements in the SRC
system since 1991.) I will be happy to help out in updating them or
making them available on the net.

(By the way, I think it's great that you are asking all these
 questions. Unfornately, this week I don't have time to try to post
 something coherent to answer some of your questions.  Keep the
 questions coming though!)

-- Farshad
--
Farshad Nayeri
nayeri@gte.com


======================================================================= 37 ===
Date:    7 Apr 1995 15:40:34 GMT
From:    sims@linux.acsys.com (dave sims)
Subject: Static linking on Solaris SOLsun?

I managed to compile and run my M3 application under Solaris using the
SOLsun distribution.  Woohoo!  Everything worked except when I tried
to fork a second threads.  Then I got an assertion in ThreadPosix.m3,
line 1473.

But that's not my main problem.  How can I statically link my
application under SOLsun?  I'm trying to take my application to a
different Solaris box that doesn't have all the M3 dynamic libraries
on it.

Any suggestions for static linking on SOLsun?

thanks,
dave sims
-- 
Dave Sims                     I'm an anarchist, and I vote.
sims@usa.acsys.com            Don't tread on me.
http://www.acsys.com/~sims/   Finger or WWW for PGP key.
KC5JKN


======================================================================= 38 ===
Date:    Fri, 7 Apr 1995 17:32:51 GMT
From:    dduggan@nuada.uwaterloo.ca (Dominic Duggan)
Subject: tips on installing 3.5.2 on solaris with gcc

[Posted to fill gaps I found in the notes with the distribution,
and with the hope it may help some who want to get m3 up fast
without farting around figuring this out for themselves]

1. Replace these lines in boot-SOLgnu/m3build/templates/SOLgnu

   CC = _ifdef ("CC", CC, [ "gcc", "-compat-bsd", "-fpic" ])
   BOOT_CC =  [ "gcc", "-compat-bsd" ]

   with

   CC = [ "m3-gcc", "-compat-bsd", "-fpic" ]
   BOOT_CC =  [ "m3-gcc", "-compat-bsd" ]

   respectively.  You may want to temporarily copy boot-SOLgnu/m3-gcc
   to a directory in your search path (just while booting compiler).

2. Edit quake/src/makefile, replace "CC = cc" with "CC = gcc"

3. Having installed the compiler, but before installing the libraries, type

   setenv LD_LIBRARY_PATH /usr/local/lib/m3/SOLgnu

   or wherever you are putting the libraries.
   (This is a bit of a surprise to me, your mileage may vary...)
-- 
Spoken: Dominic Duggan        Internet: dduggan@uwaterloo.ca
Canada: Dept of Computer Science, University of Waterloo, 
        Waterloo, Ontario, Canada N2L 3G1
WWW:    http://nuada.uwaterloo.ca/dduggan.html


======================================================================= 39 ===
Date:    8 Apr 1995 00:11:38 GMT
From:    mojemj@unidhp.uni-c.dk (Mogens Jensen)
Subject: Re: Should I learn Modula-3? How?

Fraser Campbell (fraser@wingham.com) wrote:
: I want to learn how to program.  I have dabbled in C and understand the
: basics but have never done anything very significant.  What I am wondering
: is whether Modula-3 is worth learning ... that article in Linux Journal made
: it sound very good!

: Any advice on how to learn modula-3 would be appreciated - books, text
: files, newsgroups, etc.  Also, I need some help with basic (language
: independant) program development.  I have a couple of apps in mind and just
: need some advice to get me of the ground ...  then I plan to learn as I go
: along (probably not the best way ;).  I realize that eventually C is a
: language I must become comfortable with especially using UNIX ... but
: Modula-3 sounds intriguing!

: So if you know of any good books (or whatever) outlining basic programming
: concepts and perhaps on Modula-3 please share your knowledge.  Thanks ...


Sorry, this follow-up may not be appropriate in this newsgroup - but how 
can others see if (and how) articles are responded to if you post private 
e-mail ?


Now to your question:

Maybe you _should_ learn Modula-3, but have you checked other languages ?

  I am currently looking for a language that better suits my needs; I 
currently use C++ (which really is great for some purposes, but is 
troubled by it's C heritage). If you are just starting to program you may 
want to get into the object-oriented paradigm at once (_The_Standard_ 
seems to be SmallTalk, I think I prefer Sather), or use some mixture (I 
would say Ada95, or Delphi? (Win only)) - with mixture I mean languages 
in wich you are tempted to write "good-old" algorithm-oriented programs.

It *REALLY* depends on your needs:
 - How easy must your programs be to maintain (to others) ?      (Ada may win)
 - How easy must your programs be to extend ?  (Some Object-Oriented Language)
 - How important is it that your program works (!) ?  (Ada folks say Ada wins)
 - How fast should it be to program ?  (SmallTalk wins if you are experienced)
 - How fast should your programs run ?       (*NOT* SmallTalk to my knowledge)
 - What platform(s) do you want, and at what price ?      (GNU = Good News2 U)
 - Are you going to use multitasking (concurrency) ?       (Ada wins here IMO)
 - Do you want a GUI-development environment ?          (Varies with platform)
 - Etc.

Of course there is a whole bunch of programming languages out there which 
I don't know (either) - in particular Modula-3 (which I can't use under 
DOS/WIN/OS/2 I think).


This is where I currently is:  (you probably can't use this at all)


I really like Ada95;
  - it is now an ISO-standard, which means that the language you learn 
doesn't change every year - C++ will soon be an ISO-standard, Sather are 
more experimental. SmallTalk is SmallTalk.
  - check-out: packages (with childs), tasks, protected units, The 
Rationale (this language seems big, but one doesn't have to use all the 
facilities), etc.

Sather has some very interesting facilities:
  - The single greatest thing since sliced bread is Sather Iters !  IMO
  - check-out: iters, inheritance (code seperate from interface), etc.


As of

Fraser Campbell (fraser@wingham.com) wrote:
: Also, I need some help with basic (language independant) program 
: development.  I have a couple of apps in mind and just need some advice 
: to get me of the ground ...  then I plan to learn as I go along 

just mail me (my father, that is, see sig.) if I can help; I don't know 
Linux though, if that's your platform...


Greetings from Jens Jakob Jensen, Denmark - (Using my fathers account)


======================================================================= 40 ===
Date:    7 Apr 95 14:58:23
From:    dagenais@gutrune.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: translation listing exist?

In article <SPENCER.95Apr6150656@calvin.ERA.COM> spencer@ERA.COM (Spencer Allai
n) writes:

   I was wondering if someplace there exists a repository of Examples that show
   how to implement a concept particular to another language in Modula-3.  I ju
st
   thought of asking this question because of another question I just recently
   asked concerning finalization.

   I was envisioning some type of document that would cite common questions for
   someone who wants to start using Modula-3, and has knowledge of some other O
-O
   capable language.  I can see questions like: 
     Where are the constructors and destructors?????
     What do I use for a string????

Such answers could be in the FAQ. I am currently in the process of
restructuring the FAQ to make it easier to submit items to include in
the FAQ or to store on my FTP/WWW server. Different categories of
items will be included in the FAQ, mentioned in the FAQ or simply
stored on the server. The submission process will be handled automatically
with a human simply "checking" entries.

As for the specific questions you asked, some are answered in course notes
that i have been writing lately, which are available at
http://www.vlsi.polymtl.ca/dagenais/if515/main/main.html. The
table of content is as follows:

 {chapter}{ {1}Introduction}{11}
 {chapter}{ {2}Object Oriented Programming}{13}
 {section}{ {2.1}The Evolution of Programming Languages}{13}
 {subsection}{ {2.1.1}Ada 9X}{14}
 {subsection}{ {2.1.2}CLOS}{15}
 {subsection}{ {2.1.3}Eiffel}{15}
 {subsection}{ {2.1.4}ML}{15}
 {subsection}{ {2.1.5}Modula-3}{16}
 {subsection}{ {2.1.6}Object Pascal}{16}
 {subsection}{ {2.1.7}Oberon}{16}
 {subsection}{ {2.1.8}Smalltalk}{16}
 {section}{ {2.2}Object Oriented Concepts}{16}
 {subsection}{ {2.2.1}Inheritance}{17}
 {subsection}{ {2.2.2}Class variables}{18}
 {subsection}{ {2.2.3}Encapsulation}{19}
 {subsection}{ {2.2.4}Procedure name overloading}{19}
 {subsection}{ {2.2.5}Operator overloading}{20}
 {subsection}{ {2.2.6}Methods}{21}
 {subsection}{ {2.2.7}Before and after methods}{26}
 {subsection}{ {2.2.8}Method selection based on all arguments}{28}
 {subsection}{ {2.2.9}Non virtual methods}{30}
 {subsection}{ {2.2.10}Constructors and destructors}{31}
 {subsection}{ {2.2.11}Metaclasses}{33}
 {subsection}{ {2.2.12}Exception Handling}{33}
 {subsection}{ {2.2.13}Generic Modules}{34}
 {subsection}{ {2.2.14}Substitutes for multiple inheritance}{36}
 {subsection}{ {2.2.15}Discussion}{38}
 {section}{ {2.3}Object Oriented Design}{39}
 {subsection}{ {2.3.1}The Object Model}{39}
 {subsection}{ {2.3.2}The Dynamic Model}{40}
 {subsection}{ {2.3.3}The Functional Model}{40}
 {subsection}{ {2.3.4}Analysis}{40}
 {subsection}{ {2.3.5}System Design}{41}
 {subsection}{ {2.3.6}Object Design}{41}
 {chapter}{ {3}Sample Object Oriented Languages}{43}
 {section}{ {3.1}A Simple Object Oriented Language: Obliq}{43}
 {subsection}{ {3.1.1}Single and Multiple Inheritance}{44}
 {subsection}{ {3.1.2}Class and Instance Variables and Methods}{45}
 {section}{ {3.2}C++}{46}
 {subsection}{ {3.2.1}Classes}{46}
 {subsection}{ {3.2.2}References}{48}
 {subsection}{ {3.2.3}Automatic Type Conversion}{49}
 {subsection}{ {3.2.4}Constructors and Destructors}{49}
 {subsection}{ {3.2.5}Function Name Overload}{51}
 {subsection}{ {3.2.6}Operator Overload}{52}
 {subsection}{ {3.2.7}Templates}{53}
 {subsection}{ {3.2.8}Exceptions}{53}
 {subsection}{ {3.2.9}Linkage with C}{54}
 {subsection}{ {3.2.10}Conclusion}{55}
 {section}{ {3.3}Modula-3}{55}
 {chapter}{ {4}Modular Programming}{57}
 {section}{ {4.1}Interfaces}{57}
 {section}{ {4.2}Litterate Programming}{62}
 {section}{ {4.3}Dependency Analysis}{62}
 {section}{ {4.4}Modules in Modula-3}{64}
 {chapter}{ {5}Run time Libraries and Tools}{77}
 {section}{ {5.1}Safe Language Features}{77}
 {section}{ {5.2}Debugging}{78}
 {section}{ {5.3}Coverage Analysis}{79}
 {section}{ {5.4}Performance Analysis}{80}
 {section}{ {5.5}Dynamic Memory Allocation}{81}
 {subsection}{ {5.5.1}Memory allocation errors}{81}
 {subsection}{ {5.5.2}Memory allocation algorithms}{82}
 {subsection}{ {5.5.3}Garbage collection}{83}
 {subsection}{ {5.5.4}Run time type identification}{84}
 {section}{ {5.6}Multi-threading}{84}
 {section}{ {5.7}Embedded Languages}{85}
 {section}{ {5.8}Run Time Analysis of Modula-3 Programs}{86}
 {subsection}{ {5.8.1}Run time checks}{86}
 {subsection}{ {5.8.2}Coverage Analysis}{86}
 {subsection}{ {5.8.3}Profiling}{89}
 {subsection}{ {5.8.4}Debugging}{92}
 {subsection}{ {5.8.5}Graphical tools}{97}
 {subsection}{ {5.8.6}Embedded language}{97}
 {chapter}{ {6}Object Oriented Libraries}{105}
 {section}{ {6.1}Standard Libraries}{106}
 {section}{ {6.2}The Modula-3 Standard Library}{106}
 {section}{ {6.3}User Interface Libraries}{107}
 {subsection}{ {6.3.1}Device independence}{107}
 {subsection}{ {6.3.2}Low level graphics}{108}
 {subsection}{ {6.3.3}Building blocks for toolkits}{108}
 {subsection}{ {6.3.4}Toolkits}{109}
 {subsection}{ {6.3.5}Graphical interface builders}{109}
 {subsection}{ {6.3.6}User interface and Object Orientation}{109}
 {section}{ {6.4}Trestle}{110}
 {section}{ {6.5}VBTKit}{111}
 {section}{ {6.6}FormsVBT}{112}
 {section}{ {6.7}A Complete Graphical Application Example}{112}
 {subsection}{ {6.7.1}Graphical items}{113}
 {subsection}{ {6.7.2}View: displaying items}{117}
 {subsection}{ {6.7.3}Win: user interaction}{126}
 {subsection}{ {6.7.4}The user interface}{141}
 {subsection}{ {6.7.5}The diagram editor}{148}
 {chapter}{ {7}Distributed and Persistent Objects}{163}
 {section}{ {7.1}Network Objects}{163}
 {subsection}{ {7.1.1}Remote procedure calls}{163}
 {subsection}{ {7.1.2}Network objects}{165}
 {section}{ {7.2}Persistent Objects}{166}
 {subsection}{ {7.2.1}Translation between memory and disk representations}{167}
 {subsection}{ {7.2.2}Lazy loading and unloading}{167}
 {subsection}{ {7.2.3}Persistence through reachability}{169}
 {subsection}{ {7.2.4}Updating the persistent storage}{169}
 {section}{ {7.3}Object Oriented Databases}{170}
 {subsection}{ {7.3.1}Fized size limitations}{170}
 {subsection}{ {7.3.2}Unique object identifiers}{171}
 {subsection}{ {7.3.3}The programming language versus database gap}{171}
 {subsection}{ {7.3.4}Storing procedures in the database}{171}
 {section}{ {7.4}Distributed Persistent Objects in Modula-3}{172}
 {subsection}{ {7.4.1}Network objects}{172}
 {subsection}{ {7.4.2}Persistent objects}{190}
 {subsection}{ {7.4.3}Stable persistent objects}{191}
 {subsection}{ {7.4.4}Indexing}{193}
 {subsection}{ {7.4.5}Query Processing}{196}
 {subsection}{ {7.4.6}Transactions}{197}
 {subsection}{ {7.4.7}Optimized loading and unloading}{197}
 {chapter}{ {8}Conclusion}{199}
 {chapter}{ {A}Digital License Agreement}{201}
--

Prof. Michel Dagenais        http://www.vlsi.polymtl.ca/dagenais/home/home.html
Dept of EE and Computer Eng.        dagenais@vlsi.polymtl.ca
Ecole Polytechnique de Montreal     tel: (514) 340-4029



======================================================================= 41 ===
Date:    7 Apr 95 14:42:14
From:    dagenais@gutrune.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: Modula-3 expected developments

In article <9504061347.AA08641@cloyd.East.Sun.COM> gwyant@cloyd.East.Sun.COM (G
eoffrey Wyant - Sun Microsystems Labs BOS) writes:

   variety of ways. We have developed a distributed transaction
   manager and an object activation service for Network Objects.
   I expect these will be made publically available in the 
   not too distant future. 

Great! I am starting to have a few network objects applications and
having an activation service (a la inetd.conf) will be very helpful!
Distributed transactions are neat but the underlying storage services are
still slim (Stable and SmallDB).

--

Prof. Michel Dagenais        http://www.vlsi.polymtl.ca/dagenais/home/home.html
Dept of EE and Computer Eng.        dagenais@vlsi.polymtl.ca
Ecole Polytechnique de Montreal     tel: (514) 340-4029



======================================================================= 42 ===
Date:    9 Apr 95 09:35:52
From:    nayeri@gte.com (Farshad Nayeri)
Subject: Re: Should I learn Modula-3? How?


In this long reply I will first try to answer Fraser Campbell's
questions about Modula-3. Then I will try to address some of Jens
Jacob Jensen's comments.

In article <3m4kbq$mkk@news.uni-c.dk> mojemj@unidhp.uni-c.dk (Mogens Jensen) wr
ites:

   Fraser Campbell (fraser@wingham.com) wrote: I want to learn how to
   : program.  I have dabbled in C and understand the basics but have
   : never done anything very significant.  What I am wondering is
   : whether Modula-3 is worth learning ... that article in Linux
   : Journal made it sound very good!

   : Any advice on how to learn modula-3 would be appreciated - books,
   : text files, newsgroups, etc.  Also, I need some help with basic
   : (language independant) program development.  I have a couple of
   : apps in mind and just need some advice to get me of the ground
   : ...  then I plan to learn as I go along (probably not the best
   : way ;).  I realize that eventually C is a language I must become
   : comfortable with especially using UNIX ... but Modula-3 sounds
   : intriguing!

   : So if you know of any good books (or whatever) outlining basic
   : programming concepts and perhaps on Modula-3 please share your
   : knowledge.  Thanks ...

I won't comment about introductory programming texts and ideas as my
post is very long already.

Modula-3 is a good language for learning programming where you can be
introduced to simple to advanced features one feature at a time. And
the language is complete enough that you can do a variety of tasks
when you get to them. Modula-3 will ensure the "safety" of your
programs under many situations that C and many other languages don't.
This will be allow you to learn programming without too much worry
about safety initially. As you learn more, you can program in "unsafe"
modules which is closer to the model of programming in C/C++. 

You may want to consider Sam Harbison's book "Modula-3", as it uses
something like the approach of uncovering features one thing at a
time. It covers all of the language, and it is a cross between a
tutorial and a reference to the language. I believe it is meant for
people who have some or little exposure to programming.
Unfortunately, Harbison's "Modula-3" is a bit outdated in its
description of libraries as they have changed since the print date. I
also recommend browsing around the Modula-3 home page and the Modula-3
FAQ via World Wide Web for basic information on Modula-3.

I am not sure why you are learning to program -- do you want to write
your own programs? Do you have a mandate as to what tools to use by
your employer? Are you going to try to get a job doing programming?
Depending on the answer to these questions, you may or may not have to
"be comfrotable with C". It is quite feasible under Linux to write
programs in Modula-3 without learning C. Would this look as good on
your resume as C++ experience? Probably not. But it'd certainly get
the programming job done (probably a lot faster and cleaner too.)

Sadly, Modula-3 is missing an easy-to-use programming environment for
the novice. Perhaps Oberon-2, Eiffel, and Smalltalk are better in this
respect, but the current implementations of Modula-3 are closer to the
process you go through to build C programs (if that is your ultimate
goal). Modula-3 also allows you to do "systems programming" sorts of
tasks: you can twiddle bits and talk about machine-level pointer
strucutres which will come handy if you ever move to the C world
(though the M3 assumptions are totally opposite of C assumption).

Also, I think learning by programming is a good idea as long as you
take the time to think about the process and not always "just getting
the application done". Sometime I find that people who learn by
hands-on programming just try to get the code finished, without too
much regard about the process. One problem of learning by programming
is that you get hit by syntax too soon, and that may or may not work.
Anyway, it is hard to make generalizations on this subject, so I will
stop here.

Finally, I think the choice of your platform does make a difference in
your choice of a system. On Mac, if Macintosh Pascal is still around,
it's a quite nice environment for a beginner.  Under Windows, as Jens
Jacob Jensen mentions Delphi may not be bad for a beginner. Turbo
Pascal is pretty good under DOS. Under Linux -- well probably Modula-3
is a good choice under Linux, especially if you want to get it "for
free".


                             *   *   *


Regarding Jens Jacob Jensen's remarks. I will divide them up into
several categories.

==== "I am not so sure if I agree, 
      but why should a beginning programmer care" category ====

    - How easy must your programs be to maintain (to others) ?  
      (Ada may win)

Why is this a concern for a beginner programmer? I certainly hope that
the first couple of apps that a beginner programmer writes are not
necessarily going to be maintained by others.

    - How easy must your programs be to extend ?  
      (Some Object-Oriented Language)

Again, I am not sure why this should be a concern for a beginner
programmer. Extensibility is overrated anyway given today's
programming language technology using any programming language.

==== "Huh?" category ====

    - How important is it that your program works (!) ?  
      (Ada folks say Ada wins)

What do you mean "your program works"?

==== "Can apply to many other systems including Modula-3" category ====

    - What platform(s) do you want, and at what price ?  
      (GNU = Good News2 U)

Modula-3 is also available on a variety of platforms for free. Perhaps
the only popular platforms where M3 is not accessible is the MacOS.
(Under OS/2 and Windows you can run m3pc I believe in DOS emulation
mode.)

    - Are you going to use multitasking (concurrency) ?  
      (Ada wins here IMO)

I would say that Modula-3 has a simpler concurrency model than Ada.
All important Modula-3 libraries are thread-safe, and some even take
advantage of threads (thread-friendly).

    - Do you want a GUI-development environment ?  
      (Varies with platform)

You can get one of these for free under the Modula-3 archive, called
FormsVBT. It is probably not as complete as commercial systems, but
you don't have to pay and it's good enough for many tasks. You may
also want to experiment with Visual Obliq which is a part of Modula-3
distribution.  Perhaps that will allow you to build applications fast
and play with their user interfaces, etc, like you would in Smalltalk
environment.


                             *  *  * 

Mr. Jensen goes on to say:

   Of course there is a whole bunch of programming languages out there
   which I don't know (either) - in particular Modula-3 (which I can't
   use under DOS/WIN/OS/2 I think).

There are two ports of Modula-3 which are available under DOS, which I
think you can run under emulation from OS/2, and Windows.  Modula-3
will also run under Windows'95 whenever it becomes available; it
currently runs fine on Windows/NT.

   I really like Ada95;
     - it is now an ISO-standard, which means that the language you learn 
   doesn't change every year - C++ will soon be an ISO-standard, Sather are 
   more experimental. SmallTalk is SmallTalk.
     - check-out: packages (with childs), tasks, protected units, The 
   Rationale (this language seems big, but one doesn't have to use all the 
   facilities), etc.

If you are worried about standards as a programmer who just started, I
recommend you go with IEEE-standard programming language Scheme! It is
a nice language to learn progrmming in and there are many good books
and implementations available.  Note that complying with standards
usually involves adding of a lot of crud to a language (due to varying
interests of the standard participants) which will probably make it
harder to learn the language for a beginner programmer.

Modula-3 hasn't changed much since 1989, by the way.

-- Farshad (speaking for myself)

--
Farshad Nayeri
nayeri@gte.com


======================================================================= 43 ===
Date:    10 Apr 1995 15:02:07 GMT
From:    sims@linux.acsys.com (dave sims)
Subject: Re: Static linking on Solaris SOLsun?

I wrote> I managed to compile and run my M3 application under Solaris
I wrote> using the SOLsun distribution.  Woohoo!  Everything worked
I wrote> except when I tried to fork a second threads.  Then I got an
I wrote> assertion in ThreadPosix.m3, line 1473.

Just as a side note, I upgraded from Solaris 2.3 to Solaris 2.4, and
the thread problem mentioned above went away.

-- 
Dave Sims                     I'm an anarchist, and I vote.
sims@usa.acsys.com            Don't tread on me.
http://www.acsys.com/~sims/   Finger or WWW for PGP key.
KC5JKN


======================================================================= 44 ===
Date:    Mon, 10 Apr 1995 21:53:19 GMT
From:    spencer@ERA.COM (Spencer Allain)
Subject: Re: Why you should use C++


This was just posted in comp.lang.ada, and now I believe that it should
find it's way over to Modula-3 :)  Hmm, I seem to recall someone asking
about why they might want to start programming in Modula-3.  Wouldn't it
be great to just hand them a "Why Modula-3" paper, in addition to the
FAQ?

In article <3m8ttn$d52@Starbase.NeoSoft.COM> dweller@Starbase.NeoSoft.COM (Davi
d Weller) writes:

   I'm reposting this from the comp.lang.c++ newsgroup.  I kinda like
   Robert Martin, he's a pretty level-headed person.  The reason I"m
   reposting it is that the arguments below represent the kind of things
   we need to consider as we make a business case to the commercial
   world.  Ponder his words (but don't flame him).  It'd be nice to see
   a "Why Ada" paper from a similar perspective.



				    Why C++

				Robert C. Martin
			    Object Mentor Associates
				rmartin@oma.com
				  708.918.1004

				   4 Apr 1995



				    Abstract


	     C++ is a language that seems to stimulate a tremendous  
	     amount  of  debate  and  religious  furor.   This  paper
	     attempts to cut  through this "nonsense" and make a case
	     for  why C++  is a  reasonable language  for  developing
	     object oriented applications.


   Introduction.

   Why is there so much controversy about C++?  Probably because it has
   enjoyed so much success.  It is easy to believe that if C++ had remained
   a backwater language, the voices of its detractors would not be so loud.
   However, C++ *has* succeeded in a huge segment of the industry, and the
   proponents of other languages are quite vocal in bemoaning this fact.

   But what are they really complaining about?   Ian Joyner, one of the most
   vocal and prolific C++ detractors, has published and widely distributed
   his notorious "C++??  A Critique of C++, Second Edition"  (write to
   ian@ssyacus.acus.os.au for a copy).  This is a generally well written
   (although in my opinion misguided) paper, and I recommend it to anyone
   considering C++ as a language.  In this paper Ian says: "...the C
   base is C++'s greatest weakness."  And this is a common thread through
   many of the arguments against C++.  They say that C++ is a bad language
   because C was a bad language.  

   I don't think that C needs a defense.  The last several decades have
   proven it to be an extremely flexible and productive language, suitable
   for building applications of nearly every kind.  However, in the early days
   of C, there were many detractors who decried the ugliness of the language
   and promoted "pure" languages like Pascal.  The current debate regarding
   C++ and other languages such as Eiffel, Obj-C and Smalltalk seems similar.

   Why did C succeed?  Because it cut through all the crap.  Instead of
   fighting for "purity", the authors of C created a language that could be
   *used*.  They never contended that it was perfect or pure, certainly it is
   not.  They wanted a simple, moderately low level language that they and
   other people could use.  In that goal, they succeeded.

   Why has C++ succeeded?  For the same reason.  It cuts through all the
   nonsense.  Instead of trying for some lofty goal of "purity", Stroustrup
   has created a language that can be *used*.  None of the users or authors
   of C++ claim that the language is perfect, or pure.  However the claims of
   its usability have been confirmed over and over again.  The language *is
   being used* more than any other language in its class.  And that usage is
   increasing at a geometric rate.

   This paper is not an attempt to answer the complaints made by C++
   detractors.  Rather it presents arguments for why C++ is a reasonable
   choice for the implementation of object oriented designs in a wide
   variety of application environments.  

   Who am I that I should write such a paper?  I am a user of C++, and the
   manager of a team of users.  I have been using C++ since 1989, and have
   been involved with object oriented technology since 1986.  I have
   produced, several large and successful systems in C++, and continue to
   enjoy such success.  I am an international consultant who works with
   engineering teams, training them in object oriented design and C++, and
   helping them with their software designs.  I am also the author of:
   "Designing Object Oriented C++ Applications using the Booch Method" by
   Robert Martin, Prentice Hall, 1995, ISBN 0-13-203837-4


   What the Deuce is Purity?

   Almost everyone can agree that C++ is not a "pure" OO language.
   However, this definition is problematic in that it implies that "purity"
   is a valid concept.  Yet, there is no accepted definition of the term
   "pure OO language".  Despite years of discussion and argument on the
   net, and in other circles, I have never seen anyone present a definition
   of a "pure OOPL" that met with general agreement by others.

   The fact that C++ is "impure" is often taken to mean that users are free
   to leave the golden path to OO and "backslide" into the unrepentant
   state of (gasp) procedural design.  However, *every* OOPL must allow
   such "backsliding", because object oriented design is a *superset* of
   procedural design.  It is *always* possible for a procedural design to
   be implemented in an object oriented language.

   This assertion is easy to prove.  A procedural design is a set of data
   structures and procedures.  In an OOPL, one can create a single object
   which contains all the data structures and procedures of the procedural
   design.  Thus, the procedural design is implemented within the confines
   of a single object.  Don't laugh!  I have talked to engineers who have
   done just this.

   So what good is purity?  I can't tell you, because I can't define it.  I
   can tell you this, however.  Purity, if it exists, does not force users
   to write good programs.  And impurity, if it exists, does not force
   programmers to write bad programs.  The main (possibley sole) ingredient
   required for good programs is good programmers.


   The Benefits of C++ as a "Better C".

   Ignoring Object Oriented programming for the moment, probably the
   biggest benefit that C++ provides is type safety.  C++ is a type safe
   language.  What does this mean?  Simply speaking it means this:

	 void f(long l) {...} // function declared in one file.

	 f(1); // in C, this can cause stack corruption since an integer
	       // is passed instead of a long.  However in C++, the
	       // compiler knows that 'f' wants a "long" and so promotes
	       // the '1' to the correct type.

   ANSI C makes type safety optional.  C++ makes it mandatory.  In C++ it
   is very difficult (not impossible) to violate the type system. 

   Why is this important?  Because type errors in C are often the causes of
   strange bugs that take weeks or months to find, and that exhibit
   transient and misleading behavior.  They often foul the stack or heap
   and cause eventual failure several million instructions after the
   precipitating event.  Such bugs are the hallmark of poor quality
   software.  C++, in a single stroke, eliminates a huge percentage of
   them.

   This advantage alone makes C++ a better alternative than C.  C
   programmers don't have to learn any of the other features of the
   language to take advantage of type safety.


   C++ is a Low Level Language with High Level Features.

   When all is said and done, C++ is a language for the manipulation of
   bits and bytes.  Although "purists" might rant and bemoan this attribute
   of C++, *engineers* sigh with relief.  All computer applications are,
   eventually, the manipulation of bits and bytes.  We might not wish this
   were so, but it is.  And C++ provides the features that allow low level
   manipulations to be effient and easy.  If, in the end, I need to store
   the bit pattern '10110100' in the byte whose address is FCA9DE, C++ will
   allow me to do so, without complaint.

   But C++ also provides many high level features, so that the user can
   "pretend" that C++ is a high level language.  This makes C++ useful in
   those places where a high level language is needed. 

   As a user, and the representative of other users, I can attest to the
   fact that C++ succeeds in this dual role.   I can implement high level
   abstractions in C++ using the high level structures of the language, and
   I can implement low level details using the low level structures of the
   language.  It all works, and works quite well.


   Object Oriented Programming.

   Without a doubt, this feature of C++ is the most important.  The reason
   is that well structured object oriented designs create applications that
   are robust, maintainable and comprised of elements that can be reused in
   other applications.   

   It must be stressed that the use of C++ does not guarantee that
   applications will have these desirable attributes.  In fact, C++ does
   not even "nudge" the user in the right direction.  And neither does any
   other language!  Bad designs are BAD DESIGNS, period.  No language will
   correct them.  No language, regardless of its "purity" will improve a
   bad design.  

   An Object Oriented design is a difficult thing to create.  Using an OO
   programming language does not guarantee that the design will be object
   oriented.  In fact, the design should be expressible indepedently of the
   language.  It is for this reason that Object Oriented design notations
   (e.g. Booch, or OMT) have been developed.  

   There is a large contingent of developers who believe that object
   oriented design is simply the partitioning of the application into
   representative objects.  Such designs can be represented in the design
   notations, and can be implemented in OO programming languages.  However,
   most often these designs do not follow the principles of object oriented
   design.

   Object oriented designs should have certain attributes.  Those
   attributes include the structuring of source code dependencies such that
   source code modules that implement the detailed parts of the
   application are isolated from the source code modules that implement the
   high level policies, or business rules, of the application.  Moreover,
   the detailed modules should depend upon the high level modules, and the
   high level modules MUST NOT depend upon any of the detailed modules.  

   This management of dependencies is the key design activity needed to
   produce robust, maintainable and reusable designs.  And yet very many
   designers that are new to OO do not understand this.  No language,
   regardless of its OO "purity" will help a designer manage the
   dependencies between high level details and low level policies.   

     --  [ I   have  written  a   paper  that   describes ]
     --  [ dependency  management, and  it  is  also well ]
     --  [ covered in my book.  If  you would like a copy ]
     --  [ of  the paper, send  me  some email  and  I'll ]
     --  [ send it to you.    rmartin@oma.com             ]

   Once an object oriented design has been created, C++ is an excellent
   language in which to implement it.  Once implemented, all the advantages
   of the design are exhibited by the source code.  The modules created are
   robust in that they are isolated from changes made in other modules,
   they are maintainable in that the engineers need not fear that changes
   in one module will ripple to other modules, and they are reusable in
   that the high level modules do not depend upon the low level details,
   and so can be reused in a different detailed context.


   Run Time Efficiency.

   There are two broad classifications of Object Oriented languages:
   Statically typed languages like C++ and Eiffel, and dynamically typed
   language like Smalltalk or Objective-C.  Both of these language types
   employ "run time binding" which is the attribute that makes object
   oriented design possible.  However, the mechanisms employed by the two
   different language types are very different.

   In dynamically typed languages, every run time binding is looked up in a
   table of some kind.  Although table lookups can be very fast, they still
   involve a loop, and a token matching algorithm.  Hash tables are common,
   and some calls can even be resolved at compile time.  Generally,
   however, it is impossible to precisely describe the time required for
   such an operation.  And generally the operation requires dozens, or even
   hundreds of microseconds.  Since a well designed object oriented program
   will make the majority of its function calls via this mechanism, the
   runtime overhead of a dynamic type system can be significant.

   In statically typed languages, run time bindings are performed by
   indexing into a table of pointers.  This operation always requires
   exactly the same amount of time, and can be theoretically reduced to a
   single index into an array followed by a single pointer dereference.  On
   most machines of today's calibre, these operations require less than a
   microsecond total.

   Most implementations of C++ come very close to achieving the theoretical
   limit, adding only one or two other pointer dereferences or index
   operations.  For each implementation, the time required can be exactly
   specified.

   Thus, run time efficiency of run time bindings in statically typed
   language is always better than that of dynamically typed languages.
   What requires one or two microseconds in C++ may require dozens or
   hundreds of microseconds in a dynamically typed language.

   This makes C++ an excellent choice for applications that have intense
   real time requirements.    It also makes C++ a good choice for component
   libraries that *might* be used in intense real time applications.


   Memory Managment.

   C++ is one of the very few OO programming language that does not require
   dynamic memory management.  Perfectly sound OO programs can be
   implemented without using the "heap" at all.   This is extremely
   important to those industries that have regulations against "heap"
   usage.  (e.g. Avionics.)  Objects can be created on the stack just like
   auto variables, or they can be created statically.  In such cases, there
   is no need for memory cleanup, and no risk of heap fragmentation or
   exhaustion. 

   C++ is the one of the only languages that allows the programmer to have
   complete control over the way memory is managed.  If the user wants to
   use a heap, he can.  If he wants to implement his own heap, he can.  If
   he wants some objects to be created on the heap, and other objects to be
   created on a separately managed heap, he can.  If he wants his heap to
   be garbage collected, he can implement or buy the appropriate collector.
   I know of no other language that provides such flexibility.

   C++ is often "bashed" because it does not provide garbage collection.
   The argument proferred is often: "GC is intrinsic to OO.  GC is needed
   to free the programmer from managing memory.  The lack of GC imposes
   extra complexity on the design."  Irrespective of the truth or falsity
   of these arguments, there is another argument to be made:  "Programmers shou
ld
   have complete control over how memory is managed."  I know of no
   language that provides more control over this area than C++.  

   The point is this.  If you really think that you need garbage
   collection, then you can have it.  It won't be neatly integrated into
   the language, and there will be a certain amount of difficulty involved,
   however you can gain the bulk of the advantages of a garbage collected
   environment if you absolutely need them.  However, if you don't need
   them, (and very often you don't) you don't have to have them.  In this,
   C++ is unique.

   But what about memory leaks?  Yes, this is a problem.  Any consciencious
   programmer should deal with this issue.  There are several ways.  First,
   you can get a garbage collector.  Second, you can use a tool like
   Purify, or Bounds Checker.  Third, you can use an environment like
   ObjectCenter for tracking heap problems.  Fourth, you can write your own
   heap allocator and put your own tracing mechanisms in.  Fifth, you don't
   need to use the heap at all.

   OK, then what about heap fragmentation?  Yes, this too is a problem.
   However it is almost trivial to write an allocator that can't be
   fragmented.  Stroustrup describes such an allocator in "The C++
   Programming Language" 2d. ed.  And Rogue Wave sells one in the Booch
   Component library.  C++ allows you to use such an allocator instead of
   the standard (malloc based) allocator.


   Third Party Sources and Support.

   C++ is by far the most supported object oriented language.  There are
   compilers for nearly every major platform out there.  There are even
   cross compilers for embedded systems.  Moreover there is a large and
   growing supply of third party tools and class libraries.   No other
   object oriented language even comes close to the coverage and sourcing
   that C++ enjoys.


   C++ derives from C.

   Although this point is often counted as an argument against C++, I count
   it as an advantage of the language.  It means that C++ programs can be
   easily integrated with legacy C code, and legacy code in other languages
   that are C callable.  C++ programs can call C programs, and C programs
   can call C++ programs.

   Moreover, C++ inherits all of the attributes that make C such a
   successful and useful language.  Although C++ is a bigger and more
   complex language than C, it still "feels" like C.  This is a subjective
   point, but one that is not insignificant.


   Conclusion

   Wait a minute!  Is that all?  Aren't there more reasons to use C++ than
   that?  Sure.  There are lots of little details that I passed over.  Why?
   Because they are details, and because they can be contentious.  I could
   tell you how great templates are, or how wonderful operator overloading
   is, or how neat pure virtual functions are.  But why?  For every point I
   could make, someone else could refute it and say it is ugly or nasty.
   And who should you believe?  Your best recourse is to find out about these
   features for yourself.  I recommend that you do a lot of reading.  Then
   examine the arguments, pro and con, and decide for yourself.  Don't
   hesitate to drop me a line asking me what I think about this or that.
   (rmartin@oma.com).

   But isn't C++ ugly?  Part of it, yes.  So what?  English is an ugly
   language too.  Ask any Frenchman.  Consider the word "garage".  This is
   an ugly word.  Listen to it.  Yuck!  But we don't often see the "ugliness"
   of the word because we *use* it to represent a concept that is not ugly
   at all.  The same is true of C++.  Yes, I can understand why some people
   would think that some of the features or syntax of C++ are ugly.  But
   the concepts underneath are not.  Once you begin using the language, the
   "ugliness" evaporates.

   I have not been trying to tell you that C++ is the only OOPL and all
   wisdom dies with it.  I have not been trying to tell you that C++ is the
   language you should be using.  I have simply been trying to tell you
   why I use it, and why I think it is a reasonable implementation language
   for object oriented designs.  

   If you want to use some other language, do so.  It's no skin off my
   apple.  But don't fall prey to the religious arguments of C++
   detractors.  C++ is a great language.  It will not corrupt you, nor drag
   you down into the hell reserved for mediocre programmers.  Nor will it
   turn you into "Super-Programmer" able to leap tall specifications with a
   single switch/case statement.  No language has such powers!  Software is
   not a religion.

   C++ is a language.  It is a good language.  It is a usable language.
   And if you are interested in implementing object oriented designs, it
   will work for you.







   -- 
   Robert Martin       | Design Consulting   | Training courses offered:
   Object Mentor Assoc.| rmartin@rcmcon.com  |   Object Oriented Analysis
   2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
   Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++


   -- 
	 Frustrated with C, C++, Pascal, Fortran?  Ada95 _might_ be for you!
	     For all sorts of interesting Ada95 tidbits, run the command:
   "finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as sub
j.)
		   if u cn rd ths, u r gd enuf to chg to Ada   :-)

-Spencer Allain    spencer@era.com
Engineering Research Associates
Vienna, VA  22182


======================================================================= 45 ===
Date:    Wed, 12 Apr 1995 10:58:07 +0200
From:    franz@inf.ethz.ch (Michael Franz)
Subject: Announcement: Oberon Track at GISI'95

The First Joint Conference of GI and SI will have a major track
dedicated to Oberon. There will be an Oberon tutorial, four talks,
and a plenary discussion. The conference language will be German,
but the proceedings (to be published by Springer-Verlag) will contain
English versions of the papers.

All this will happen on Monday, September 18th, 1995.

Here are the abstracts of the talks:

---

The Smart Document or How to Integrate Global Services

Jurg Gutknecht
Institut fur Computersysteme
ETH Zurich, CH-8092 Zurich
gutknecht@inf.ethz.ch


Driven by a foreseeable significant increase of global services
(cable and wireless) in the near future, client/server environments
will progressively replace systems that operate a single computer
or workstation in isolation. Modern operating systems will not merely
be expected to access but to integrate global services as smoothly
as possible, because it is unreasonable to require users to learn a
different interface for every single service that they want to use.
Services should be presented uniformly and called implicitly, i.e.
service-specific technical details should be handled by the system
unconspicuously and behind the scenes.

We believe that the document-oriented approach is best suited to
this purpose. We present and demonstrate a versatile document-
oriented interface for Oberon that - currently - integrates local
documents, visual objects, symbolic computation servers, Web and
Teletext. 

---

Integrating Oberon Resources into the World-Wide Web

Ralph Sommerer
Institut fur Computersysteme
ETH Zurich, CH-8092 Zurich
sommerer@inf.ethz.ch


The World-Wide Web (WWW) is currently one of the most popular
network information systems on the Internet. The range of items that
may be accessed within the WWW includes hypertext documents,
images, sound patterns and video sequences.
To identify these items, their location and the method to acquire them,
a generic naming scheme is provided. Besides the identification of these
items it allows to specify and parametrize activities that construct items
"on-the-fly". Hence, aspects of interaction may be introduced to the
information system.

In our paper we discuss this interactive potential power of the WWW,
especially how to obtain this power from the Oberon operating
system. Our attention is directed to aspects
of information provision, i.e. we explore the suitability of the Oberon
system for a WWW information server. The objective is the integration of
interactive Oberon applications and services in the global WWW
document space. Hence, we allow remotely to invoke Oberon
activities which produce textual or graphical data from any
location in the world. The integration is based on a simple server
framework that allows to attach Oberon services to the WWW
with minimal implementation effort.

---

A Comparison of C++, FORTRAN 90 and Oberon-2 for Scientific Programming

Bernd Moesli
ARITHMETICA
CH-8307 Effretikon, Switzerland
moesli@arithmetica.ch


In the past decade, the programming languages C++, FORTRAN 90 and Oberon-2
all evolved from their ancestors. This invites to reflect upon the
suitability of these modern programming languages for scientific and
engineering computing. In the first part, we compare their primary language
features, as needed by scientists and engineers. In the second part, we
list some useful features missing in Oberon-2. The report concludes by a
personal assessment of the three languages with respect to the numerical
context. The reader's experience in scientific programming in C or FORTRAN
would be advantageous.

---

Oberon Dialogs: A User Interface for End Users

Markus Knasmueller
Institute for Computer Science (Systemsoftware)
Johannes Kepler Universitaet, Altenbergerstrasse 69, A-4040 Linz
knasmueller@ssw.uni-linz.ac.at


This paper describes the Dialogs package which allows a user to create and
use dialog viewers with buttons, check boxes, text fields and other user
interface elements. Dialogs fit smoothly into the Oberon system. Existing
tools can be equipped with a graphical user interface without
modifications. The object-oriented nature of Dialogs allows adding new user
interface items and new commands even by third party programmers and end
users.

---

Conference Program:
Monday, September 18th, 1995.

08.30-11.30 Oberon-Tutorial (Gutknecht, Reiser)

13.45-14.30 Gutknecht: Smart Documents
14.30-15.00 Sommerer: World-Wide-Web
15.00-15.15 Coffee Break
15.15-15.45 Moesli: Scientific Programming
15.45-16.15 Knasmueller: Oberon Dialogs
16.15-16.55 Plenary Discussion (Niklaus Wirth and others)

---

For general questions about GISI'95, please contact gisi95@inf.ethz.ch
or look up http://www.inf.ethz.ch/GISI95/GISI95.html .

Michael Franz


======================================================================= 46 ===
Date:    Wed, 12 Apr 95 15:58:14 -0700
From:    heydon@pa.dec.com
Subject: SRC Modula-3 linker algorithm (was: enigmatic smuggling)


My previous description of how the SRC Modula-3 linker decides which
interfaces and modules to include when it builds a program had a small
mistake. When the linker builds the reachability graph, it adds a
*bi-directional* edge for each EXPORTed interface.

A complete description of the algorithm is now available on the Web as
part of the SRC Modula-3 documentation. See the URL:

  http://www.research.digital.com/SRC/-
    modula-3/html/linking/LinkingProgs.html

The figures in the examples were drawn with Juno-2, a constraint-based
drawing editor written in Modula-3. See the following URL for more
information about Juno-2.

  http://gatekeeper.dec.com/pub/DEC/SRC/-
    research-reports/abstracts/src-rr-131a.html

I also hope to create a Juno-2 "home page" in the near future.

- Allan

--------------------------------------------------------------------
Allan Heydon                           Digital Equipment Corporation
heydon@pa.dec.com                      Systems Research Center
(415) 853-2142                         130 Lytton Avenue
(415) 853-2104 (FAX)                   Palo Alto, CA 94301


======================================================================= 47 ===
Date:    Thu, 13 Apr 1995 06:07:03 GMT
From:    cs_wcm@ug.cs.ust.hk (Woo Chat Ming)
Subject: Trestle or Motif ?

I want to learn programming in windows. I have two choice :
I can use Trestle in Modula-3 or use Motif in C++. Which one
is more powerful and which one is more easy to use ?

Woo Chat Ming.



======================================================================= 48 ===
Date:    Thu, 13 Apr 1995 14:52:23 -0400
From:    gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS)
Subject: Trestle or Motif ?

Woo Chat Ming writes:
 > I want to learn programming in windows. I have two choice : > I can
 use Trestle in Modula-3 or use Motif in C++. Which one > is more
 powerful and which one is more easy to use ?  > > Woo Chat Ming.  >

Trestle, VBTKit, and FormsVBT (which is UIMS with a Motif'ish look to
it built on Trestle) are far more powerful than Motif/C++.

Trestle is a garbage-collected, concurrent UI toolkit, where as
Motif/C++ is single threaded and requires manual storage
management. For ease of learning about programming in window systems,
Trestle and FormsVBT really can't be beat.

--geoff

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

2 Elizabeth Drive
Chelmsford, Ma.
01824


======================================================================= 49 ===
Date:    Fri, 14 Apr 1995 00:41:32 GMT
From:    hgeorge@eskimo.com (Harry George)
Subject: Re: Trestle or Motif ?

In article <1995Apr13.060703.27267@uxmail.ust.hk>, cs_wcm@ug.cs.ust.hk 
says...
>
>I want to learn programming in windows. I have two choice :
>I can use Trestle in Modula-3 or use Motif in C++. Which one
>is more powerful and which one is more easy to use ?
>
>Woo Chat Ming.
>

Why not do Motif in Modula-3?  What you need is a M3 binding for
Motif (and for specific widgets).  I still can't release my Xm.i3 
bindings from work, but maybe we could jointly do the bindings in
our spare(?) time from home.


Motif is _the_ standard in much of the UNIX work world.  Using it with
Modula-3 can be fun. Not as powerful or clean as Trestle, but usable.
Used with named parameters (courtesy of M3), X/Motif can be readable.  
Of course  multithreading goes to hell, but you can lock the X-driver
thread, mess with multithreads in normal M3, and then release the 
X thread.  Just don't try to do multithreads while X is running.
-- 
--------------------
Harry George
email: hgeorge@eskimo.com
smail: 22608 90th Ave W / Edmonds WA 98026
quote: <under construction>



======================================================================= 50 ===
Date:    13 Apr 1995 18:34:24 GMT
From:    schwartz@galapagos.cse.psu.edu (Scott Schwartz)
Subject: Re: Trestle or Motif ?

cs_wcm@ug.cs.ust.hk (Woo Chat Ming) writes:
| I want to learn programming in windows. I have two choice :
| I can use Trestle in Modula-3 or use Motif in C++. Which one
| is more powerful and which one is more easy to use ?

You might want to consider using Tk.  It's smaller, faster, and easier
than Trestle or Motif.  You can use Tk from C or C++, probably from M3
also.



======================================================================= 51 ===
Date:    13 Apr 1995 23:38:20 GMT
From:    strand@nic.cerf.net (Parallel Performance Group)
Subject: Software Announcement


Parallel Performance Group (PPG) is a provider of high-tech Unix- and  PC-based
scientific,  engineering,  and graphics software.  PPG publishes a free monthly
electronic-mail Newsletter for each of the categories below.   Each  Newsletter
covers  material  on  the market/industry niches served by these categories and
tutorial information on the technologies involved.  By sending an e-mail letter
to any mailbox shown below, you will obtain by return e-mail sample Newsletters
for the particular area(s) of your interest.  You will not be put on any mail-
ing list unless you specifically ask to be.

Category                    Software Products         Auto-Response E-Mail Box
-------------------------   -----------------------   ------------------------
Obj.-Oriented CASE Tools    Oberon/F, case/4/0,       obj@ppgsoft.com
                             objectiF, Innovator,
                             Wizdom-Pro, Loox 

RealTime DSP                Rippen, Hypersignal       dsp@ppgsoft.com
Image Proc'g/Medicl Imgng   IAP                       img@ppgsoft.com
Fuzzy Logic/Fuzzy Control   Fuzzy Control Manager     fuz@ppgsoft.com
Neural Networks             NeuroCom, NeuroGraph      neu@ppgsoft.com
Project Management          Accent, ACOS PLUS 1       prm@ppgsoft.com
Volume Visualization        Vox-L, IAP                vis@ppgsoft.com
Simulation                  SystemSpecs, GPSS         sim@ppgsoft.com

RealTime Multiprocessing/   Rippen, Express,          mpr@ppgsoft.com
 Parallel Processing/        Strand88, HyperC, 
 Distributed Processing      Load Balancer,
                             MUSIC, Pulsus

Solid Modelling/CADD/       Prelude, Pytha, Unicad,   sol@ppgsoft.com
 Mech. Design/Animation      Point Line, 3DGO

Graphical Application       Loox GAI Design Tool      gai@ppgsoft.com
 Interfaces

To regularly receive any Newsletter, reply to subscribe@ppgsoft.com with the 
message "Subscribe <category>".  For example, "Subscribe Multiprocessing".


======================================================================= 52 ===
Date:    Fri, 14 Apr 1995 00:28:34 GMT
From:    hgeorge@eskimo.com (Harry George)
Subject: Re: Why you should use C++

In article <SPENCER.95Apr10175319@calvin.ERA.COM>, spencer@ERA.COM 
says...
>
>
>This was just posted in comp.lang.ada, and now I believe that it 
should
>find it's way over to Modula-3 :)  Hmm, I seem to recall someone 
asking
>about why they might want to start programming in Modula-3.  Wouldn't 
it
>be great to just hand them a "Why Modula-3" paper, in addition to the
>FAQ?
>
[long discussion skipped]

"Why <xyz>?" papers abound, but they don't change anyone's mind.  The 
other guy
just keeps on saying, "Well, so what? My language can do the job, 
too."

IMHO, the problem is this:
   a) A Turing Machine can do any computable task, and can be 
      programmed by punching holes in a paper tape.
   b) Anything more abstract or sophisticated than that is for the 
      convenience of humans.
   c) A great deal has been learned about how humans (both programmers
      and compiler writers) interact with programming languages.
   d) Language designers try to incorporate these insights into new 
      languages.
   e) Some languages sacrifice functionality in the attempt to
      incorporate new insights -- I consider these to be interesting
      experiments, but not production ready.
   f) Some languages pile features on, accreting functionality
      but losing clarity. These are useable but costly to maintain.
   g) A few languages are both functional (in the sense of effective)
      and elegant.  These are useable in a wide range of tasks, and 
are 
      a joy to develop and to maintain.  Also, they can readily be
      converted to the next silver bullet when it shows up.
   h) It is difficult to understand the differences
      among languages unless you see the same task done in several
      languages, set side-by-side.


"h" is not just a matter of opinion.  It is subject to verification.
For example, a panel of multi-lingual programmers could review code
written in several languages, all doing the same tasks.  Use an
Olympic scoring system:  Artistic and technical scores 
given separately.  Range 0-6.  Throw out high and low, and average 
the remainder.

I've been trying to set up that experiment.  I prepared applications 
in M3 and locally asked people to replicate them in their favorite 
languages.  I chose tasks which should highlight the positives of 
specific languages or language classes.  The tasks include:
    - "Hello, world" in X/Motif with a few buttons and textfields
    - Bit twiddling
    - Matrix manipulation, built as a template so it is useable with 
      various numeric types (IEEE 32bit, 64Bit, 80bit)
    - SQL database access and update, and printing a tabular formatted
      report.
    - System stuff (forks, execs, timers,...)
    - Lisp-like defun and eval (define a function, put it in a 
      polymorphic list, then cdr down the list to find the function
      and eval it)
    - [I intend to add] "5 houses" problem from Prolog
    - [I do not have an example for embedded systems -- is anyone
      actually doing embedded systems in M3?  How does one handle
      static addressing of objects or keep tight control of the heap?]

I've had no luck getting samples from other languages.  So maybe the 
net is the place to do this sort of thing.  Anyone want to help?
   - Chose other/additional representative tasks
   - Build Modula-3 examples 
     (or imporve on mine -- this was 2 weeks total effort)
   - Build <xyz> examples (at least Ada, C, C++, Prolog, Lisp, ML,
     Sather, Eiffel, C+@, Dylan, Oberon-2,...)
   - Serve as a juror (you have to prove multi-lingual experience)
   - Spread the word that it is time to put-up-or-shut-up re languages

Temporarily at least we could use comp.lang.modula3 for coordination.
Later, maybe comp.lang.misc could host the code-offs.  


--------------------
Harry George
email: hgeorge@eskimo.com
smail: 22608 90th Ave W / Edmonds WA 98026
quote: <under construction>



======================================================================= 53 ===
Date:    Thu, 13 Apr 1995 13:06:58 -0400
From:    Dick Orgass <orgass+@CMU.EDU>
Subject: Re: Trestle or Motif ?

I've used both Trestle and the Motif library to build applications and,
as a result, my view is the following.

If your application can be constructed from a few Motif widgets, then a
C or C++ simplementation of the application is quite simple.  However,
it's stil easier to use Tk/Tck or Tk/Perl for applications of this sort.

For an application of some substance, that is something that's more than
just a rearrangement of some standard widgets with a bit of glue,
Trestle and the accompanying libraries are, in my opinion, easier.  This
is in an area where reasonable people might disagree.  The Trestle
version will be multi-threaded producing a more lively application.

For a complex application, there's no question in my mind that Trestle
and friends are far better than the Motif library.  To quickly make my
point, consider writing the Trestle/FormsVBT mail program, Postcard. 
The Modula-3 code is simple and clean.  Think about what it might be
like to write this using Motif and X directly, even in Modula-3.  I'm
sure you'll conclude that the Trestle/FormsVBT version is much cleaner
and simpler, not to mention more functional.

All of the above are more or less technical arguments.  The marketplace
has a quite different idea.  Skills in Motif and C or C++ are valued
much more highly than skills in Trestle/FormsVBT and Modula-3.  I don't
endorse this state of affairs but it is reality.

Dick


======================================================================= 54 ===
Date:    Thu, 13 Apr 1995 22:39:59 GMT
From:    fmc@world.std.com (Fraser M Campbell)
Subject: What's the best Tutorial for Modula-3?

Thanks to all those who responded to my previous post in this group.  What I
was wanting (I probably didn't make this clear) was a recommendation on the
best tutorial style book for Modula-3.  I need something along the lines of
the beginner C books you can buy, not something that already assumes you're
an expert programmer.

Please give me specific titles and ISBN numbers (which are not in the FAQ ;)
... if you can't give me an ISBN then please try to tell me the publisher at
least.  I am eagerly awaiting your numerous recommendations ...

Thanks!


======================================================================= 55 ===
Date:    13 Apr 95 22:54:46
From:    nayeri@gte.com (Farshad Nayeri)
Subject: Re: What's the best Tutorial for Modula-3?


Fraser Campbell says:

   Thanks to all those who responded to my previous post in this
   group.  What I was wanting (I probably didn't make this clear) was
   a recommendation on the best tutorial style book for Modula-3.  I
   need something along the lines of the beginner C books you can buy,
   not something that already assumes you're an expert programmer.

Your best bet is:

   Samuel P. Harbison, Modula-3, Prentice Hall, ISBN 0-13-596396-6, 1992. 
   -- A complete Modula-3 textbook covering the full
      language, with examples and exercises. Includes a style manual
      and a user's guide for SRC Modula-3.

   I got this information from the Modula-3 bibliography page,
   http://www.research.digital.com/SRC/modula-3/html/bib.html)

Also see the errata sheet for the same book:
   ftp://gatekeeper.dec.com/pub/DEC/Modula-3/errata/

-- Farshad
--
Farshad Nayeri
nayeri@gte.com


======================================================================= 56 ===
Date:    14 Apr 95 07:37:11
From:    nayeri@gte.com (Farshad Nayeri)
Subject: Re: TSrg, TImpl in NetObj

In article <D70E2A.3yz@undergrad.math.uwaterloo.ca> wyrmok@plg.uwaterloo.ca (Ru
ssell Mok) writes:

   I went through the NetObj reference manual(SRC report 115) but I am
   not sure whether I have to explictly to write codes for TSrg and
   TImpl which are subtypes of NetObj.T. The manual says that the stub
   generator will declare the surrogate type(TSrg), but exactly how? To
   be more specific, if I have the following declaration:

   TYPE T = NetObj.T OBJECT
              METHODS
                x();
              END;

   do I have to declare a type TSrg and TImpl somewhere in the module?
   Should I give an implemention of T.x() or TImpl.x()?

   I don't know if I have made my question clear enough. I guess I do
   know the run-time relationships between T, TSrg and TImpl but I am
   confused in how they are generated.

Russell,

You don't need to code TSrg; stubgen will create it for you. As far as
I know, unless you are doing something tricky, you should not be
concerned with TSrg in your code. In fact, in simple cases you don't
_need_ to declare TImpl either. For example, you could do:

INTERFACE I;
TYPE T = NetObj.T METHODS op() END;
END M.

MODULE M;
IMPORT NetObj;
IMPORT I;

PROCEDURE Op(self: I.T) RAISES ... = BEGIN ... END Op;
BEGIN
  NetObj.Export (NEW(I.T, op := Op));
END M.

Here by calling NEW on I.T and overriding the implementation of op, I
get away with exporting a netobj without having to declare a TImpl. (I
guess TImpl = I.T in this case.) But this means you won't be able to
associate any individual state to an exported I.T object, as I.T is a
"pure" type.

Many times you _do_ want to associate individual state to an exported
object, so can make a subtype of I.T and declare some state for the
subtype.  This is why you may want to have a TImpl type in your
module. Note that NetObj needs is that TImpl is a subtype of I.T. You
can name TImpl anything you wish and pretty much declare it anywhere
you'd like in your code.

MODULE M; 
IMPORT NetObj, I;

TYPE 
  TImpl = I.T OBJECT
    state: ... := ...;
  METHODS
    op := Op;
  END;

PROCEDURE op(self: TImpl) RAISES ... = 
BEGIN 
... refer to self.state ...
END op;

BEGIN 
  NetObj.Export (NEW(TImpl)); 
END M.

Good luck! Hope this helps, -- Farshad

For a longer explanation, see Geoff Wyant's Linux Journal article 
"Introducing Modula-3", ftp://ftp.gte.com/pub/m3/linux-journal.html:

To turn an object type into a network object, that object must inherit
(either directly or indirectly) from the type 'NetObj.T'. The object
cannot contain any data fields. The interface containing the
declaration is then run through a tool called a stub compiler. This
generates all code necessary to handle network interactions. That's
all that is required to allow an object to be passed around the
network. Pretty simple. Below is an example of a network object. It
defines an interface called "File" that defines the operations on a
file, and an implementation of that interface.


        INTERFACE File;

        TYPE T = NetObj.T OBJECT
        METHODS
          getChar(): CHAR;
          putChar(c: CHAR);
        END; 

        END File; 

        INTERFACE FileServer;
        IMPORT File;
        
        TYPE T = NetObj.T OBJECT
        METHODS
          create(name: Text): File.T;
          open(name: Text): File.T;
        END;

        END FileServer;


The above defines two types: "File.T", which is an object with two
methods to get and put a single character resp; and "FileServer.T", an
object which manages file objects. A server someplace defines a
concrete implementation of these abstract types.


        MODULE FileServerImpl;
        IMPORT File, FileServer;

        TYPE FileImpl = File.T
        ...state for a file...
        OVERRIDES
          getChar := GetChar;
          putChar := PutChar;
        END; 

        TYPE FileServerImpl = FileServer.T OBJECT
        ...state for a file server...
        OVERRIDES
          create := Create;
          open := Open;
        END; 

        VAR
          fileServer := NEW(FileServerImpl);
        BEGIN
           NetObj.Export("FileServer", fileServer);
        END;

        MODULE FileServerClient;
        IMPORT File, FileServer;
        
        VAR
          fileServer := NetObj.Import("FileServer");
          file := fileServer.Create("someFile");
        BEGIN
          file.putChar('a');
        END FileServerClient;

In the above, 'FileServerImpl' creates an instance of a file server
and puts it into a name server (this is what 'NetObj.Export' call
does). The module 'FileServerClient' (which would be running in a
different address space or machine) 'imports' the file server
implementation. This gives a valid Modula-3 object back to the client.
>From that point on, the client invokes methods on it as if it were
local. It then creates a File object which it begins adding characters
to.

--
Farshad Nayeri
nayeri@gte.com


======================================================================= 57 ===
Date:    14 Apr 95 06:55:00
From:    nayeri@gte.com (Farshad Nayeri)
Subject: unwritten style guidelines for designing Modula-3 interfaces


I am writing down some of the "unwritten style guidelines". Evidently
there are some at SRC, I have seen at least two posts regarding these
unwritten "rules":

Paul McJones says about exceptions vs. checked run-time errors:

   While designing Modula-3 libraries at SRC, our philosophy has been
   to treat conditions that could only be caused by client programming
   error as checked runtime errors rather than as declared exceptions.
   So in general, input/output errors are treated as exceptions.  (The
   interface IO is itself an exception!  It was designed to be as
   "Pascal-like" as possible, for teaching a first course in
   programming.)

Mark Manasse says regarding locking levels:

   [Valuable information about locking levels in Trestle deleted.]
   A while ago, David Sternlicht asked about experience with locking
   levels, and with the locking strategies used in Trestle. [...]
   Over the years, we've even gained a few converts: when you write a
   large system, it just gets too hard to keep it all in your head
   [...].

Anyone care to elaborate on other such conventions? (Few of the simple
ones are documented in an appendix of Sam Harbison's Modula-3, but the
documentation is not extensive.)

- procedures vs. methods on principal type
- New() vs. NEW() vs. init() and their expected semantics
- multiple inheritence workaround
   (via opaque types?)
- dealing with import dependency cycles
- naming conventions
- interface commenting style
- bit fields are bad
- any others?

I can come up with my own interpretation of these unwritten rules, but
it is better to get a first-hand account, I think. Such a set of
guidelines (with proper examples and explanation ultimately ) would be
very useful for the intermediate Modula-3 programmer. I will be happy
to collect the answers and repost a summary.

-- Farshad
--
Farshad Nayeri
nayeri@gte.com


======================================================================= 58 ===
Date:    Fri, 14 Apr 1995 05:03:46 GMT
From:    wyrmok@plg.uwaterloo.ca (Russell Mok)
Subject: TSrg, TImpl in NetObj

I went through the NetObj reference manual(SRC report 115) but I am
not sure whether I have to explictly to write codes for TSrg and
TImpl which are subtypes of NetObj.T. The manual says that the stub
generator will declare the surrogate type(TSrg), but exactly how? To
be more specific, if I have the following declaration:

TYPE T = NetObj.T OBJECT
           METHODS
             x();
           END;

do I have to declare a type TSrg and TImpl somewhere in the module?
Should I give an implemention of T.x() or TImpl.x()?

I don't know if I have made my question clear enough. I guess I do
know the run-time relationships between T, TSrg and TImpl but I am
confused in how they are generated.

Thanks in advance.

Russell



======================================================================= 59 ===
Date:    Fri, 14 Apr 95 13:03:09 -0700
From:    heydon@pa.dec.com
Subject: Re: unwritten style guidelines for designing Modula-3 interfaces

Farshad,

Another convention is the use of "Public" and "Private" types in
relation to opaque types. Section A.1.4 of Harbison's book is a good
start on this subject, but it could go further. Certainly,

  INTERFACE Foo;
  IMPORT Bar;
  TYPE
    T <: Public;
    Public = Bar.T OBJECT <fields-and-methods-1> END;
  ...
  END Foo.

is the most common idiom used with respect to opaque types, but often
the introduction of the name "Public" is only for the convenience of
the implementer of the interface. It allows the revelation to be
expressed as:

  MODULE Foo;
  REVEAL T = Public OBJECT <fields-and-methods-2> END;
  ...
  BEGIN ... END Foo.

However, the introduction of the new type "Foo.Public" could have been
avoided by writing:

  INTERFACE Foo;
  IMPORT Bar;
  TYPE T <: Bar.T OBJECT <fields-and-methods-1> END;

The disadvantage to this approach is that the declarations for the
<fields-and-methods-1> would then have to have been *repeated* in the
concrete revelation, like this:

  MODULE Foo;
  IMPORT Bar;
  REVEAL T = Bar.T OBJECT <fields-and-methods-1> END OBJECT
    <fields-and-methods-2>
  END;

As you can see, the former approach makes the implementer's job
easier, but not the client's, since it introduces an extra (you might
even say unnecessary) name. So implementers sometimes take the second
approach. For example, the generic "Table" interface does not
introduce the names "Table.Public" or "Table.DefaultPublic". If you
look at "Table.mg", you will see that all the public methods in the
definition of "Table.Default" (appearing in "Table.ig") are repeated
in the concrete revelation. (You will also see that the name "Public"
is also introduced in the module for convenience).

In contrast to the "gratuitous" use of the "Public" type, the use of
the "Private" type to define an object prefix is often necessary. This
is well-described in chapter 6 of SPwM3, especially in the third
paragraph from the bottom of page 143. The example discussed there is:

  INTERFACE Wr;
  TYPE T <: ROOT;
  ...
  END Wr.

  INTERFACE WrClass;
  IMPORT Wr;
  TYPE Private <: ROOT;
  REVEAL Wr.T = Private OBJECT <fields-and-methods-1> END;
  ...
  END WrClass.

  UNSAFE MODULE WrRep EXPORTS Wr, WrClass, ...;
  REVEAL Private = MUTEX BRANDED OBJECT <fields-and-methods-2> END;
  ...
  BEGIN ... END WrRep;

This is a classic example of the partial revelation of an opaque type,
and it also demonstrates nicely the use of a "Private" prefix type.
Clients that import only "Wr" see none of its fields or methods.
Clients that import "Wr" and "WrClass", see only the first group of
fields and methods.

The key is to notice that by declaring a "Private" type that is a
*prefix* of the type "Wr.T", the implementation "WrRep" can reveal
that a "Wr.T" is actually a "MUTEX" object. Hence, the code in the
module "WrRep" can lock objects of type "Wr.T".

If instead the traditional idiom involving "Public" had been used in
"WrClass", like this:

  INTERFACE WrClass;
  IMPORT Wr;
  REVEAL Wr.T <: Public;
  TYPE Public = ROOT OBJECT <fields-and-methods-1> END;
  ...
  END WrClass.

then there would be no way to reveal that "Wr.T" was actually a
subtype of a "MUTEX". Instead, the "MUTEX" object would have to
have been imbedded as a field of the "Wr.T", like this:

  UNSAFE MODULE WrRep EXPORTS Wr, WrClass, ...;
  REVEAL Wr.T = Public BRANDED OBJECT
    mu: MUTEX;
    <fields-and-methods-2>
  END;
  ...
  BEGIN ... END WrRep;

This approach is much less convenient for the implementer of "WrRep",
since the type "Wr.T" is not a mutex.

- Allan

--------------------------------------------------------------------
Allan Heydon                           Digital Equipment Corporation
heydon@pa.dec.com                      Systems Research Center
(415) 853-2142                         130 Lytton Avenue
(415) 853-2104 (FAX)                   Palo Alto, CA 94301


======================================================================= 60 ===
Date:    16 Apr 1995 13:37:09 GMT
From:    connolly@www18.cern.ch (Dan Connolly)
Subject: Java-style interfaces (protocols) in M3, ILU?


Has anybody looked at the way Java[1] gets around multiple inheritance?

I don't think they invented the concept -- I think it's been
in Objective C for a while...

Anyway, a Java interface[2] is a sort of object type with no
"home" in the object hierarchy.

In contrast to M3, where method calls, at runtime, involve
an dispatch via an array of methods, ala:

	obj.classtype.methods[i](params)

Java method dispatch is by "name," where the name of a method
is its identifier and the names of the types of the parameters.
It looks a lot like smalltalk method dispatch.

I'd like to see this sort of thing supported in an ILU binding
for Java, at least.

I have noodled on what M3 language changes would acomodate this sort
of thing, but I haven't found anything I like.

What do other folks think?

[1] http://java.sun.com/
[2] http://java.sun.com/1.0alpha2/doc/javaspec/javaspec_6.html#HEADING46
--
Daniel W. Connolly        "We believe in the interconnectedness of all things"
Research Technical Staff, MIT/W3C
<connolly@w3.org>             http://www.w3.org/hypertext/WWW/People/Connolly


======================================================================= 61 ===
Date:    15 Apr 1995 13:32:41 -0700
From:    rro@Tera.COM (Rod Oldehoeft)
Subject: Re: What's the best Tutorial for Modula-3?

Someone (why doesn't this Pnews include the article in followup?)
asked about the best tutorial for M3.  Of course that is Harbison's
"Modula 3", published by Prentice-Hall, ISBN 0-13-596404-0 or
0-13-596396-6 (paper), 1992.

Rumor has it that this will appear in a revised Second Edition
sometime, with errata applied, updated SRC M3 info, and more
additional goodies.

In the meantime, this is it.



======================================================================= 62 ===
Date:    Mon, 17 Apr 1995 01:41:34 GMT
From:    cwr@crash.cts.com (Will Rose)
Subject: M3 for OS/2?


Does anyone know the status of the M3 port mentioned in the 
FAQ?  I tried email to the two addresses mentioned, but they
both bounced.

Will
cwr@crash.cts.com



======================================================================= 63 ===
Date:    Mon, 17 Apr 1995 04:11:01 -0400
From:    "Daniel C. Wang" <dw3u+@andrew.cmu.edu>
Subject: M3 runtime system.

Just curious, but are there any modula3 systems that use a runtime system,
particularly the GC, written almost entirely in modual3 itself. I'm curious,
because a number of other higher level languages (Lisp,Scheme,ML...) seem to
resort to C hackery when it comes to the runtime system. I'm wondering if
modula3 is an exception to the rule. 



======================================================================= 64 ===
Date:    17 Apr 95 08:16:08
From:    nayeri@gte.com (Farshad Nayeri)
Subject: Re: M3 runtime system.

In article <QjYW_J600aw94Cmot_@andrew.cmu.edu> "Daniel C. Wang" <dw3u+@andrew.c
mu.edu> writes:

   Just curious, but are there any modula3 systems that use a runtime
   system, particularly the GC, written almost entirely in modual3
   itself. I'm curious, because a number of other higher level
   languages (Lisp,Scheme,ML...) seem to resort to C hackery when it
   comes to the runtime system. I'm wondering if modula3 is an
   exception to the rule.

Daniel, Modula-3's run time can be written entirely in Modula-3,
including the garbage collector. SRC Modula-3 is almost entirely
written in Modula-3 [1]. As you note, this sets Modula-3 apart from
many other "high-level" languages: Modula-3 defines an unsafe subset,
so it is more convenient for machine-level programming tasks such as
writing the garbage collector.  This is unlike most other comparable
"safe" languages. (Some people have informally call a "systems
prorgramming language" one which you can use to write its own run-time
subsystem.)

The boundaries of what makes a language a "systems programming
language" are not too clear, however. A "higher-level" language
*without* an unsafe subset but *with* a native compiler subsystem may
have the same "machine-level" programming power as Modula-3. This
langauge & native subsystem pair allow you to write your garbage
collector "in the same language". 

There are at least three advantages for having an unsafe portion _as a
part of the language_:

  - for the most extent, you can treat your unsafe code the same as
    your safe code -- they all have interfaces; they have .i3 and .m3
    files; the language tools and editors will work on both, etc. And
    you don't need a C compiler. In other languages, the unsafe
    portions -- which are normally the most intricate -- fall through
    the cracks, are badly documented, and are hard to deal with.

  - your unsafe code will work the same in different compilers; its
    semantics are language-defined, unless otherwise noted in the
    language spec. This is a blessing since you would probably have to
    deal with platform portability problems in your unsafe portions
    already.

  - the language can make adequate measures to get its safety practices
    out of your way in the unsafe portions of your code. It is
    difficult to do unsafe programming if you have to worry about the
    garbage collector and concurrency on every statement.

Modula-3 is one of the few languages that carefully (and elegantly)
walks the lines of safe and unsafe programming. (As evidence, see
IMPORT rules for safe and unsafe interfaces.) Most other "high-level"
languages punt on unsafe portions where _implementations_ of those
language will have to provide access to unsafe operations.
"Lower-level" languages' normal assumption is that you are programming
in unsafe mode.  Modula-3, _the language_, allows you to program in
safe mode conveniently, but provides adequate support for you in case
you want to program in unsafe mode (to write a garbage collector, for
example!).

[1] SRC Modula-3 implements certain parts of the thread switching code
    in C. I don't know why this is, and I would be surprised if it
    can't be done otherwise. Also, SRC compiler currently generates a
    m3main.c file in C. Other than these two -- and for the ability to
    link in C code, you don't need a C compiler for either compiling
    or even bootstrapping the SRC Modula-3 compiler.

-- Farshad
--
Farshad Nayeri
nayeri@gte.com


======================================================================= 65 ===
Date:    18 Apr 95 00:01:47 GMT
From:    eaiu378@taurus.oac.uci.edu (Audrey Toy)
Subject: Question

I have a question about modula3. Who was the key designer and when was the
year of initial ful design? What is the significance and origin of it's name?
Could I have a brief histiry of modula3?
please send reply to atoy@clyde.ics.uci.edu

Thanks!!!



======================================================================= 66 ===
Date:    Tue, 18 Apr 1995 03:25:47 GMT
From:    beatty@beatty.slip.netcom.com (Derek Beatty)
Subject: building SRC 3.5.2 on a NEXTstation

Has anyone successfully built 3.5.2 including Trestle on a NEXTstation  
under NEXTSTEP 3.2?   What's the secret?

I succeeded in getting some of the basics up by ripping out the "-posix"  
flag and writing my own macros for S_IFDIR and WEXITSTATUS (NEXT's posix  
support is in 3.2 is rumored to be buggy), but when I try to compile a  
long list of files, m3 hangs with a runtime error (Segmentation violation  
- possible attempt to dereference NIL).  I don't think I'm out of virtual  
memory: when it hangs, the virtual size is only 7.14M, and I have 20M  
physical memory and about 15M free on the partition containing the  
swapfile.  If I run gdb on m3 and attach to the hanging process, the stack  
trace looks like this:

#0  0xcf960 in RTHooks__AllocateOpenArray ()
#1  0xc86ea in IntIntTbl__NewBuckets ()
#2  0xc7f94 in IntIntTbl__Init ()
#3  0x9f016 in MxOut__WriteUnits ()
#4  0xa724 in Main__DumpLinkInfo ()
#5  0x6d6e in Main__CleanUp ()
#6  0xd3a2c in RTProcess__InvokeExitors ()
#7  0xd3aca in RTProcess__Crash ()
#8  0xe4148 in RTMisc__EndError ()
#9  0xe40a2 in RTMisc__FatalErrorPC ()
#10 0xce77c in RTSignal__SegV ()
#11 0x50083ac in _sigtramp ()
#12 0xd67f6 in RTCollector__Move ()
#13 0xd5916 in RTHeapMap__Walk ()
#14 0xd521a in RTHeapMap__DoWalkRef ()
#15 0xd517a in RTHeapMap__WalkRef ()
#16 0xd8c44 in RTCollector__CleanBetween ()
#17 0xd89fa in RTCollector__CopySome ()
#18 0xd8064 in RTCollector__CollectSomeInStateOne ()
#19 0xd7638 in RTCollector__CollectSome ()
#20 0xd7094 in RTCollector__CollectEnough ()
#21 0xd9e9a in RTCollector__LongAlloc ()
#22 0xd9afe in RTHeapRep__AllocForNew ()
#23 0xcf05a in RTHooks__Allocate ()
#24 0x5c624 in Constant__Create ()
#25 0x5c530 in Constant__ParseDecl ()
#26 0x7105e in Decl__Parse ()
#27 0x296de in Module__Parse ()
#28 0x91536 in M3Compiler__DoCompile ()
#29 0x912f0 in M3Compiler__Compile ()
#30 0xd254 in Main__Pass0 ()
#31 0xc15a in Main__PushOneM3 ()
#32 0xbde0 in Main__CompileM3 ()
#33 0xb03c in Main__CompileOne ()
#34 0xae2c in Main__CompileEverything ()
#35 0x6cf4 in Main__DoIt ()
#36 0x12c54 in _INITM_Main ()
#37 0xcea9c in RTLinker__RunMainBodies ()
#38 0xceba6 in _INITM_RTLinker ()
#39 0x2962 in main (argc=31, argv=0x3fffadc, envp=0x3fffb5c) at  
_m3main.c:1430

--
Derek Lee Beatty
beatty@netcom.com     ,(((|)))-K    ,(((|)))-K    ,(((|)))-K
Austin, Texas           ^   ^         ^   ^         ^   ^   


======================================================================= 67 ===
Date:    18 Apr 1995 12:30:58 GMT
From:    Quentin Stafford-Fraser <fraser@europarc.xerox.com>
Subject: Re: unwritten style guidelines for designing Modula-3 interfaces

nayeri@gte.com (Farshad Nayeri) wrote: 
 
>I am writing down some of the "unwritten style guidelines". Evidently 
>there are some at SRC 
... 
>- procedures vs. methods on principal type 
 
Yes, this has puzzled me in the past.  Why do we have PutText as a   
procedure in Wr, rather than as a method of a Wr.T?  The latter seems   
much more aesthetically pleasing, as well as saving typing :-)  There are   
plenty of similar examples.  
 
Is it just to avoid the small performance and memory overhead? Or is this   
a legacy of Modula-2? 
 
Quentin 
--  
 --------------------------------------------------------------------- 
                       Quentin Stafford-Fraser 
           http://pelican.cl.cam.ac.uk/people/qs101/me.html 
 --------------------------------------------------------------------- 




======================================================================= 68 ===
Date:    18 Apr 1995 10:42:22 -0400
From:    bm@news.cs.columbia.edu (Blair MacIntyre)
Subject: building SRC 3.5.2 on a NEXTstation

>>>>> On Tue, 18 Apr 1995 03:25:47 GMT, beatty@beatty.slip.netcom.com
>>>>> (Derek Beatty) said:

Derek> Has anyone successfully built 3.5.2 including Trestle on a NEXTstation  
Derek> under NEXTSTEP 3.2?   What's the secret?

Never tried, but your error (dereferencing NIL) is the same thing that
happened to me under HP-UX when I tried to use the newer version of
the m3gcc backend.  Try using the older 2.5.7-based backend.



======================================================================= 69 ===
Date:    18 Apr 95 21:10:48 GMT
From:    elessar@helios.acm.rpi.edu (Kenneth Lareau)
Subject: Binaries for Solaris 2.4?

Hello folks, I was wondering if perchance there are already some compiled
binaries for the latest (or nearly latest) version of Modula 3 for Solaris
2.4 available somewhere on the net? I would gladly attempt to compile it
myself, were it not for the fact that I simply don't have the disk space for
the compile, though I do for the final executables (assuming I've been told
correctly about that as well, can anyone give me a good estimate of the size
of a complete distribution?).

Any information on this matter would be greatly appreicated. Thank you.


Ken Lareau
elessar@helios.acm.rpi.edu


======================================================================= 70 ===
Date:    19 Apr 95 01:41:09 GMT
From:    ffung@clyde.ICS.UCI.EDU ("Frederick C. Fung")
Subject: MODULA3 history

Hi Professionals:

Can anyone help me find out the following information: year of
        initial full design, key designer, significance, and (optionally)
        origin of its name about "MODULA3"?
e.g. for PROLOG:
            . Here is a sample answer. prolog was first implemented in 1972 by
            Alain Colmerauer's research group in Marseille, France. Prolog was
            the first language based on a procedural interpretation of first
            order predicate calculus. prolog stands for programming logic.

thanks in advance.


======================================================================= 71 ===
Date:    19 Apr 95 07:01:18
From:    nayeri@gte.com (Farshad Nayeri)
Subject: Re: MODULA3 history


ffung@clyde.ICS.UCI.EDU ("Frederick C. Fung") writes:

   Can anyone help me find out the following information: year of
   initial full design, key designer, significance, and (optionally)
   origin of its name about "MODULA3"?

eaiu378@taurus.oac.uci.edu ("Audrey Toy") writes:

   I have a question about modula3. Who was the key designer and when
   was the year of initial ful design? What is the significance and
   origin of it's name?  Could I have a brief histiry of modula3?

Hmm. Sounds like extra credit for a comparative languages course. Why
this is relevant to study of languages is beyond me.

Hint: How about checking out books on M3 or at least the Modula-3 home
page? I bet you can find something there.

-- Farshad

--
Farshad Nayeri
nayeri@gte.com


======================================================================= 72 ===
Date:    Wed, 19 Apr 1995 10:50:48 -0400
From:    gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS)
Subject: Re: M3 runtime system.

	<NAYERI.95Apr17081608@tahoe.gte.com>Cc: m3@src.dec.com
In-Reply-To: <NAYERI.95Apr17081608@tahoe.gte.com>
Distribution: world
X-Received: from suneast.East.Sun.COM by East.Sun.COM (4.1/SMI-4.1)
X-Received: by src-mail.pa.dec.com; id AA29949; Wed, 19 Apr 95 08:04:00 -0700
X-Newsgroups: comp.lang.modula3
X-Content-Length: 1017
X-Received: from cloyd.East.Sun.COM by suneast.East.Sun.COM (5.0/SMI-4.1-900117
)
X-Received: from Sun.COM by inet-gw-1.pa.dec.com (5.65/24Feb95)
X-Received: by cloyd.East.Sun.COM (5.x/SMI-SVR4)
X-Received: from East.Sun.COM (east.East.Sun.COM) by Sun.COM (sun-barr.Sun.COM)
X-Received: by src-news.pa.dec.com; id AA03513; Wed, 19 Apr 95 08:04:03 -0700

Farshad Nayeri writes:
 > 
 > [1] SRC Modula-3 implements certain parts of the thread switching code
 >     in C. I don't know why this is, and I would be surprised if it
 >     can't be done otherwise. Also, SRC compiler currently generates a
 >     m3main.c file in C. Other than these two -- and for the ability to
 >     link in C code, you don't need a C compiler for either compiling
 >     or even bootstrapping the SRC Modula-3 compiler.
 > 
 > -- Farshad

Actually, the thread switching code is all in Modula-3. On POSIX systems
it does some rather sophisticated magic involving setjmp and stack analysis
to do this in a portable fashion (most C implementations of threads that
I've encountered have are a hairball of #ifdefs to get around various
processor dependencies). That POSIX thread's implementation is about
1500 lines of M3 code, including the code to do thread switching. 

--geoff

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

2 Elizabeth Drive
Chelmsford, Ma.
01824


======================================================================= 73 ===
Date:    19 Apr 1995 06:52:45 GMT
From:    laszlo@bornholm.ifi.uni-klu.ac.at (Laszlo BOESZOERMENYI)
Subject: Re: Modula3 and Oberon2.



You might read my paper:
A Comparison of Modula-3 and Oberon-2
(Structured Programming 1993 14:15-22.

Best regards
Laszlo Boszormenyi


======================================================================= 74 ===
Date:    18 Apr 1995 21:13:51 GMT
From:    drake@PROBLEM_WITH_INEWS_DOMAIN_FILE (Joshua Drake)
Subject: Does anyone know where.. COMPLETE src for Linux? m3


I am looking for the complete src tree for modula-3, for linux. The one on 
sunsite seems to be missing some very important things.. (like the makefile).
If anyone can direct me please let me know via e-mail.

					Joshua
					drake@transport.com
--

#############################################################################
=============================================================================
= drake@transport.com 				 The Admin with an attitude =
=============================================================================

	As long is there are tests... There WILL be PRAYER in SCHOOLS.
#############################################################################



======================================================================= 75 ===
Date:    Thu, 20 Apr 1995 18:50:00 +0100
From:    vgr@gaia.psdn.org (vgr)
Subject: (none)

SUBSCRIBE comp.lang.modula3 Vic Reyes


======================================================================= 76 ===
Date:    Thu, 20 Apr 95 12:06:21 -0400
From:    nayeri@gte.com (Farshad Nayeri)
Subject: Siphon documentation


I looked around, but couldn't find any reports or documents on Siphon. 
Is there such a document? 

Thanks, -- Farshad



======================================================================= 77 ===
Date:    Thu, 20 Apr 1995 14:53:45 -0400
From:    gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS)
Subject: Siphon documentation

Farshad Nayeri writes:
 > 
 > I looked around, but couldn't find any reports or documents on Siphon. 
 > Is there such a document? 
 > 
 > Thanks, -- Farshad
 > 

There is a report from DEC-PRL describing an ealier incarnation
of Siphon (I believe it was written in M2+ and thus didn't
use Network Objects). Thue functionality was essentially the same
as the current Siphon implementation. If you look under
	gatekeeper.dec.com:/pub/DEC/PRL/reports
I think you will find the report.

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

2 Elizabeth Drive
Chelmsford, Ma.
01824


======================================================================= 78 ===
Date:    19 Apr 1995 21:11:05 -0400
From:    bm@news.cs.columbia.edu (Blair MacIntyre)
Subject: pickling part of an object


Let's say I have an object T for which I want to write a custom pickle
routine.   There is a large amount of data in T that I don't want to
pickle, since I can regenerate it from a few small data value.  

So, I can write a pickling routine for it.

However, what happens to subclasses?  I don't want to lose all their
data when they get pickled using my pickler.

Is there a way to use the RTHeap interface, as Pickle does, to only
pickle out the data fields of the subclasses, not of the object
itself?




======================================================================= 79 ===
Date:    21 Apr 1995 06:51:15 GMT
From:    laszlo@bornholm.ifi.uni-klu.ac.at (Laszlo BOESZOERMENYI)
Subject: Re: What's the best Tutorial for Modula-3?


> I need something along the lines of
> the beginner C books you can buy, not something that already assumes you're
> an expert programmer.

Such a book is just in preparation at Springer Verlag
in German and in English.

L. Boszormenyi, C. Weich:

Programming in Style --
An introduction into Programming with Modula-3

The book is written for beginners.
It starts with the basic concepts of structured programming
and the corresponding Modula-3 constructs.
The second part of the book addresses more advanced topics,
such as object-oriented and parallel programming as well.
It contains a great number of examples and appendices,
such as a full and short description of the language,
a somewhat bigger, non-trivial example,
a guide how to get M3 and the examples of the book etc.

We will put the table of content into this newsgroup soon.

The German version should appear before the end of June 95,
the English version in autumn, maybe October 95.

Best regards
L. Boszormenyi


======================================================================= 80 ===
Date:    22 Apr 1995 02:18:52 GMT
From:    egustafs@ecepc44.uccs.edu (Eric Gustafson)
Subject: modula3.el maintainer?

I found a bug in the modula3.el code, but can't figure out who to
report it to.  (Actually I have the fix for it too :).  I remember
getting the code from somewhere in the U.K., and the beginning of the
file is included below.  The problem is that it parses '\\', and "\\"
as an unterminated character/string.  

---- Snip, Snip ----
;;; Last modified on Fri Feb 11 16:08:05 PST 1994 by detlefs
;;;      modified on Fri May 15 17:13:12 PDT 1992 by heydon

;;;      modified on Thu Apr 23 17:45:03 PDT 1992 by muller
;;;      modified on Fri Feb  2 13:04:24 1990 by discolo
;;;      modified on Tue May  2 21:59:35 1989 by ellis
;;;      modified                             by Trevor Morris
;;;      modified                             by Tom Perrine
;;;      modified                             by Michael Schmidt
;;;      modified                             by Peter Robinson
;;;      modified                             by mjordan

;; LCD Archive Entry:
;; modula3|Eric Muller|muller@src.dec.com|
;; Modula-3 mode.|
;; 92-04-17||~/modes/modula3.el.Z|
---- Snip, Snip ----

Thanks,
--
Eric Gustafson                                    egustafs@ecepc44.uccs.edu
Electrical & Computer Engineering                    egustafs@cpe.valpo.edu
University of Colorado -- UCCS                        Phone: (719) 637-8022
** Warning ** Planet is 97% full please remove unneeded inhabitants !!


======================================================================= 81 ===
Date:    23 Apr 1995 03:22:09 GMT
From:    mlw2374@omega (Tai West)
Subject: Re: MODULA3 history

Frederick C. Fung (ffung@clyde.ICS.UCI.EDU) wrote:
: Hi Professionals:

: Can anyone help me find out the following information: year of
:         initial full design, key designer, significance, and (optionally)
:         origin of its name about "MODULA3"?

Modula-3 corrects many of the deficiencies of Pascal and Modula-2 for
practical software engineering.  In particular, Modula-3 keeps the 
simplicity and type saftey of these earlier languages while providing new 
facilities for exception handling, concurrency, object-oriented program-
ming, run-time typing, generics, support for multithreaded applications,
and automatic garbage collection.  

Modula-3 was designed by Luca Cardelli, Jim Donahue, Mick Jordan, Bill 
Kalsow, and Greg Nelson as a joint project by DEC's Digital Systems 
Research Center (SRC) and the Olivetti Research Center.  Modula-3
was implemented at SRC by Bill Kalsow and Eric Muller.

I got this information from the book "Modula-3" by Samuel P. Harbison, and
"Introducing Modula-3" in the December 1994 Linux Journal.
--
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  @			   @   When one has good wine,			   @
  @  Tai West		   @   A graceful schooner,			   @
  @  mlw2374@omega.uta.edu @   And a maiden's love,			   @
  @			   @   Why envy the immortal gods?		   @
  @    			   @			-LI T'SI PO (A.D. 705-762) @
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@


======================================================================= 82 ===
Date:    Sun, 23 Apr 1995 00:28:15 GMT
From:    groener@vt.edu (Markus K. Groener)
Subject: Where is Klaus Preschern?

Hi,
we are searching for Klaus Preschern. In his documentation of EX32.DOC he 
gives an address for the University of Klagenfurt but e-mail to this address 
bounced back (user unknown).

Klaus, in the documentation you write that you subscribe to this group, please 
send us your new e-mail address if possible.

Thanks,

Markus (email: groener@vt.edu)
& Utku (email: utku@csgrad.cs.vt.edu)



======================================================================= 83 ===
Date:    Sun, 23 Apr 1995 00:22:45 GMT
From:    groener@vt.edu (Markus K. Groener)
Subject: Problem with starting Modula-3 on PC

Urgent!

Today we installed your DOS implementation of Modula-3 on a PC.
This is a Gateway 2000 486DX2/50MHz with 8MB RAM running MS-DOS 6.20.
Since we initially ran into lots of different problems we changed the CONFIG.SY
S and
AUTOEXEC.BAT files to reflect only the necessary commands as shown in the 
EX32.DOC documentation. Still whenever running EX after having the SETLIBPC.
BAT program run we would receive an error message. We have tried to work 
around this and load the VSSH shell manually but still received the same error 
message. Here is the output of trying to start EX32 -v vssh:

ex32 1.01, (C)opyright 1994 Klaus Preschern, All rights reserved.
Coprocessor detected.
XMS driver detected
XMS query: total: 5035 K = 5155840 bytes, free: 5035 K = 5155840 bytes
XMS linear base: 3232768 first page: 790 last page: 2047
XMS allocated: total: 0 K, free: 0 K
Physical system memory 65517568 bytes
Virtual system memory 125829120 bytes
panic: memory size is not a multiple of the page size (4096).

Running just EX we would receive the last error line without all the other 
output. We hope this will help in pointing us into the right direction. 
Please let us know if further information is need.

Thanks a lot in advance for any help. A quick response will be greatly 
appreciated.

Markus (email: groener@vt.edu)
& Utku (email: utku@csgrad.cs.vt.edu)




======================================================================= 84 ===
Date:    23 Apr 1995 07:35:10 GMT
From:    mlw2374@omega (Tai West)
Subject: Re: MODULA3 history

Tai West (mlw2374@omega) wrote:
: Frederick C. Fung (ffung@clyde.ICS.UCI.EDU) wrote:
: Hi Professionals:

: Can anyone help me find out the following information: year of
:         initial full design, key designer, significance, and (optionally)
:         origin of its name about "MODULA3"?

Modula-3 corrects many of the deficiencies of Pascal and Modula-2 for
practical software engineering.  In particular, Modula-3 keeps the 
simplicity and type saftey of these earlier languages while providing new 
facilities for exception handling, concurrency, object-oriented program-
ming, run-time typing, generics, support for multithreaded applications,
and automatic garbage collection.  

Modula-3 was designed by Luca Cardelli, Jim Donahue, Mick Jordan, Bill 
Kalsow, and Greg Nelson as a joint project by DEC's Digital Systems 
Research Center (SRC) and the Olivetti Research Center.  Modula-3
was implemented at SRC by Bill Kalsow and Eric Muller.

The first description of the language was published by Digital and Olivetti
in August of 1988.  A revision based on implementation experience was pub-
lished in 1989, and a few final adjustments were made in 1990.

Modula-3's immediate ancestor is the language Modula-2+, designed at SRC in
the early 1980s as an in-house development language.  Modula-2+ is an upward-
compatible extension of Niklaus Wirth's Modula-2 language, which in turn is
a succesor to Wirth's Pascal.

I got this information from the book "Modula-3" by Samuel P. Harbison, and
"Introducing Modula-3" in the December 1994 Linux Journal.

--
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  @			   @   When one has good wine,			   @
  @  Tai West		   @   A graceful schooner,			   @
  @  mlw2374@omega.uta.edu @   And a maiden's love,			   @
  @			   @   Why envy the immortal gods?		   @
  @    			   @			-LI T'SI PO (A.D. 705-762) @
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@




















======================================================================= 85 ===
Date:    Sun, 23 Apr 1995 00:25:43 GMT
From:    groener@vt.edu (Markus K. Groener)
Subject: M3 Documentation on Concurreny????

Hello,
is there any documentation and/or examples available on the internet that 
gives information on writing concurrent programs using threads and mutual 
exclusion in Modula-3?

Any pointers to information will be appreciated.

Markus (email: groener@vt.edu)
& Utku (email: utku@csgrad.cs.vt.edu)


======================================================================= 86 ===
Date:    23 Apr 1995 11:43:07 GMT
From:    mrg17@cus.cam.ac.uk (M.R. Gray)
Subject: Re: Problem with starting Modula-3 on PC

Markus K. Groener (groener@vt.edu) wrote:
: Urgent!
: message. Here is the output of trying to start EX32 -v vssh:

: ex32 1.01, (C)opyright 1994 Klaus Preschern, All rights reserved.
: Coprocessor detected.
: XMS driver detected
: XMS query: total: 5035 K = 5155840 bytes, free: 5035 K = 5155840 bytes
: XMS linear base: 3232768 first page: 790 last page: 2047
: XMS allocated: total: 0 K, free: 0 K
: Physical system memory 65517568 bytes
: Virtual system memory 125829120 bytes
: panic: memory size is not a multiple of the page size (4096).

As I use the EX32 for the PC, I have just pulled the patch from 
src.doc.ic.ac.uk, I enclose the readme
README file for ex32.exe version 1.03

This file should come together with "ex32.exz" - the new gzipped
ex32.exe 1.03. It should solve the following problems:

"panic: memory size is not a multiple of the page size (4096)."
"panic: not enough RAM."
"panic: pager: attempt to free a not allocated block."

For installation do:

        gzip -d ex32.exz
        copy ex32.exe \ex32\bin\ex32.exe

If you use the system with XMS, the memory size reported by XMS is
used to determine the size of available RAM.

If you run it *without* XMS, use the "-v" option to check wether the
reported physical memory size is correct. If NOT, you can specify the
memory size instart ex32 with:

        initdrvs files ex32 -v -m8192 /ex32/bin/vssh
        
Enjoy!

        Klaus Preschern

End of README file for ex32.exe version 1.03

--
-----------------------------------------------
Malcolm Gray
Trinity Hall, Diploma in Computer Science

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


======================================================================= 87 ===
Date:    Sun, 23 Apr 1995 20:47:28 GMT
From:    groener@vt.edu (Markus K. Groener)
Subject: Re: Problem with starting Modula-3 on PC - Thanks

In article <3ndegb$t3g@lyra.csx.cam.ac.uk> mrg17@cus.cam.ac.uk (M.R. Gray) writ
es:

>As I use the EX32 for the PC, I have just pulled the patch from 
>src.doc.ic.ac.uk, I enclose the readme
>README file for ex32.exe version 1.03

Thanks, we got the patch and the problem was solved.

Markus 
 & Utku


======================================================================= 88 ===
Date:    Mon, 24 Apr 95 00:24:04 -0700
From:    heydon@pa.dec.com
Subject: Re: M3 Documentation on Concurreny????

Markus K. Groener asks:

> is there any documentation and/or examples available on the internet that 
> gives information on writing concurrent programs using threads and mutual 
> exclusion in Modula-3?

Yes, Chapter 4 of the book "Systems Programming with Modula-3", edited
by Greg Nelson, is an excellent introduction to this subject. The
chapter is called "An Introduction to Programming with Threads", and
was written by Andrew Birrell.

If you don't have a copy of SPwM3, an earlier version of this paper
was published as SRC Research Report 35. The abstract and PostScript
for the report is available at the following URL:

  http://gatekeeper.dec.com/pub/DEC/SRC/
    research-reports/abstracts/src-rr-035.html

You can also order hardcopy reports and videotapes from us for free.
The URL for ordering SRC Research Reports and videotapes is:

  http://www.research.digital.com/SRC/publications/src-rr.html

I hope this helps.

- Allan

--------------------------------------------------------------------
Allan Heydon                           Digital Equipment Corporation
heydon@pa.dec.com                      Systems Research Center
(415) 853-2142                         130 Lytton Avenue
(415) 853-2104 (FAX)                   Palo Alto, CA 94301


======================================================================= 89 ===
Date:    Mon, 24 Apr 1995 15:38:39 GMT
From:    chan@alfrothul.uchicago.edu (C. Chan)
Subject: Modula-3 for AIX 3.2

I have been learning Modula-3 on my home Linux box with the
SRC 3.3 distribution and I think it would be useful for my
projects at work where we use IBM RS/6000s running AIX 3.2.

I looked at the distributions of 3.5.2 on gatekeeper.dec.com
and saw only a port to AIX 3.1. I contacted the maintainer of
the AIX 3.2 port and he informed me that work on that has been
set aside temporarily.

Are there any older distributions of Modula-3 available in binary
or source form for AIX 3.2? 

-- 
C. Chan	<chan@alfrothul.uchicago.edu> | "ASCII Magic Eye .Sig"
                                                 .


======================================================================= 90 ===
Date:    25 Apr 1995 23:02:54 GMT
From:    Ted Wobber <wobber@pa.dec.com>
Subject: Re: Siphon documentation

nayeri@gte.com (Farshad Nayeri) wrote:
>
> 
> I looked around, but couldn't find any reports or documents on Siphon. 
> Is there such a document? 
> 
> Thanks, -- Farshad
> 

The PRL report Geoff mentions is still pretty relevant, even though
it refers to anartifact written in Modula 2+.  The man pages for the
siphon and packagetools contain a fair amount of information as well:

	pkgsrv/src/packageserver.8
	pkgtool/src/packagetool.1
	pkgq/src/pkgq.1
	pkgfprint/src/pkgfp.1

If all else fails, I can answer questions directly.

/Ted



======================================================================= 91 ===
Date:    27 Apr 1995 02:28:49 GMT
From:    olm@Eng.Sun.COM (Ole Lehrmann Madsen)
Subject: ECOOP'95 Preliminary programme

This article was originally posted by Jorgen Lindskov Knudsen, but due
to a currently heavy delay in the news stream to/from Denmark I have
reposted this article.

---olm

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

Department of Computer Science, University of Aarhus, Denmark, and
AITO (Association Internationale pour les Technologies Objets) are
happy to invite you to:


			       ECOOP'95
			European Conference on
		     Object-Oriented Programming


		  Aarhus, Denmark, August 7-11, 1995


The ninth European Conference on Object-Oriented Programming is held
in Aarhus, Denmark. The conference aims at bringing together
researchers and practitioners from academia and industry to discuss
and exchange new developments in object-oriented languages, systems
and methods 

Printed program, including registration form for ECOOP'95 can be obtained from:

ECOOP'95
Computer Science Department
Aarhus University
Ny Munkegade 116, Bld. 540
DK-8000 Aarhus C, Denmark
Phone: +45 89 42 31 88
Fax: +45 89 42 32 55
E-mail: ecoop95@daimi.aau.dk
WWW: http://www.daimi.aau.dk/ecoop95

You are also welcome to contact us on the above address and we will
help you by answering questions about the conference or its
organization, or other issues related to ECOOP'95.

Please note, that the entire contents of the ECOOP'95 program is
available on World Wide Web (WWW) at the URL:

	http://www.daimi.aau.dk/ecoop95

You will here find many more details, including GIF, PostScript
(European A4 and US letter format) and RTF versions of the
registration forms, ready for printing, filling-in and sending to make
your registration for ECOOP'95 as easy as possible.

Please remember these important dates:

	Early registration deadline:	5. June 1995
	Conference period:		7.-11. August 1995

We are looking forward to seing you in Aarhus at the exciting ECOOP'95 event.

Jxrgen Lindskov Knudsen
Organizing Chair 

-------------------------------------------------------------------------------
Technical Program
-----------------

The ECOOP'95 technical program highlights state-of-the-art
object-oriented research results, based on the intense developments
during the last decade, resulting in object-oriented technology being
spread into nearly all areas of computer science research and
development.

Ole Lehrmann Madsen
Conference Chair 

Walter Olthoff
Program Chair 

Boris Magnusson
Panel Chair 

Wednesday, 9 August, 1995:
..........................

09.00-10.00 Keynote Address
Experiences on the Road to Object Utopia, Dave Thomas (Object
Technology International) 

10.30-12.00 Technical Session: Types
Chair: Remo Pareschi (Xerox, France) 

The Cartesian Product Algorithm, Ole Agesen (Stanford
University) 

PolyTOIL: A Type-Safe Polymorphic Object-Oriented Language, 
Kim B. Bruce, Angela Schuett, Robert van Gent (Williams
College, Williamstown) 

Object Imaging, Satish R. Thatte (Clarkson University,
Potsdam) 

12.00-13.30 Lunch 

13.30-15.00 Panel
Object Technology and the World-Wide Information Infrastructure 

Panel chair: Andreas Paepcke (Xerox PARC) 

15.30-17.00 Technical Session: Programming Languages
Chair: Markku Sakkinen (University of Jyvdskyld) 

Optimization of Object-Oriented Programs Using Static Class Hierarchy
Analysis,
Jeffrey Dean, David Grove, Craig Chambers (University of
Washington) 

Objects with Multiple Most Specific Classes, Elisa Bertino (Universita
di Milano), 
Giovanna Guerrini (Universita di Genova) 

A Marriage of Class- and Object-Based Inheritance Without Unwanted
Children,
Patrick Steyaert, Wolfgang De Meuter (Free University of
Brussels) 

17.15-18.15 Demonstration Sessions 


Thursday, 10 August, 1995:
..........................

09.00-10.00 Invited Talk
On Subtyping and Matching, Luca Cardelli (Digital Systems
Research Center) 

10.30-12.00 Technical Session: Reflective
Programming/Verification
Chair: Boris Magnusson (Lund University) 

Using Meta-Object Protocols to Implement Atomic Data Types, 
R.J. Stroud, Z. Wu (University of Newcastle upon Tyne) 

Meta-Level Programming with CodA, 
Jeff McAffer (University of Tokyo and Object Technology
International) 

An Object-Oriented Framework for the Formal Verification of
Processors,
Laurent Arditi, Hilhne Collavizza (Universiti de Nice) 

12.00-13.30 Lunch 

13.30-15.00 Panel 

Open Problems in Object-Oriented Programming 

Panel chair: Ole Lehrmann Madsen (University of Aarhus) 

15.30-17.00 Technical Session: Implementation 

Chair: Bjxrn Freeman-Benson (Carleton University) 

Incremental Mature Garbage Collection Using the Train Algorithm,
Jacob Seligmann, Steffen Grarup (University of Aarhus) 

Message Dispatch on Pipelined Processors, Karel Driesen,
Urs Hvlzle (University of California, Santa Barbara), Jan Vitek
(Universiti de Geneve) 

Do Object-Oriented Languages Need Special Hardware Support?,
Urs Hvlzle (University of California, Santa Barbara), David Ungar (Sun
Microsystems Laboratories) 

17.15-18.15 Demonstration Sessions 


Friday, 11 August, 1995:
........................

09.00-10.00 Invited Talk
Programming as an Experience: The Inspiration for Self, 
Randall B. Smith and Dave Ungar (Sun Microsystems
Laboratories) 

10.30-12.00 Technical Session: Concurrency/Specification

Chair: Oscar Nierstrasz (Universitdt Bern) 

Time and Asynchrony in Interactions Among Distributed Real Time
Objects, 
Ichiro Satoh (Keio University), Mario Tokoro (Keio
University and Sony Computer Science Laboratory) 

Object Protocols as Functional Parsers, Gert Florijn (Utrecht
University) 

Interface-Based Protocol Specification of Open Systems Using PSL, 
Doug Lea (SUNY at Oswego), Jos Marlowe (Sun Microsystems
Laboratories) 

12.00-13.30 Lunch 

13.30-15.00 Technical Session: Distribution/Interfaces 

Chair: Gerti Kappel (University of Linz) 

Experience Using Design Patterns to Evolve System Software Across
Diverse OS Platforms,
Douglas C. Schmidt (Washington University), Paul
Stephenson (Ericsson, Inc.) 

Sharing Properties in a Uniform Object Space, Heiko Kiessling,
Uwe Kr|ger (University of Karlsruhe) 

ChyPro: A Hypermedia Programming Environment for Smalltalk,
Maurice Amsellem (Universiti de Paris) 

-------------------------------------------------------------------------------
Tutorial Overview
-----------------
ECOOP'95 offers an exciting tutorial program, featuring a selection of
introductory, intermediate and advanced presentations of interest to
both researchers and practitioners. The tutorial program addresses a
broad spectrum of object technology, including methods, languages,
environments and theoretical topics. The tutorial program welcomes
both conference participants and other interrested parties.

Birger Mxller-Pedersen
Tutorial Chair 

Tutorials

T01: MOSES: Methodology for Object-Oriented Software Engineering of
     Systems
T02: Adoption and Management of OO by an Organization
T03: Prototype-Based Application Construction Using Self
T04: Using Design Patterns - Elements of Reusable Architectures
T05: Concurrent Object-Oriented Network Programming with C++
T06: Enterprise Object Modeling
T07: Object-Oriented Technology for Real-Time Systems
T08: From OOA/OOD to Eiffel 
T09: Efficient Implementation of Object-Oriented Programming Languages
T10: Oberon and Extensible Programming
T11: Integrating Formal Methods With Object-Oriented Software
     Engineering Methodologies
T12: OTI Constraint Solver
T13: Object Cobol
T14: Models and Paradigms of Interaction
T15: Programming in BETA
T16: Object-Oriented Domain Analysis: Reuse, Obstacles and Possible
     Solutions

-------------------------------------------------------------------------------
Workshop Overview
-----------------

The ECOOP'95 workshop program provides an excellent framework for
people to meet and focus on current advanced research topics as well
as discuss issues of general interest. Workshops can also help by
bridging gaps between related fields.
The workshop program is free of charge for conference participants.
Others must pay a workshop fee, which gives access to any number of
workshops. Prospective workshop attendees must submit a position
paper to the respective workshop organizer, who will grant admission
hereupon. Any additional information about a particular workshop
should be obtained directly from the workshop organizer.
Please consult the workshop organizer for specific deadlines for
position paper submissions and notification of acceptance. Please note
that further details on the individual workshops are available on the 
ECOOP'95 Workshop World Wide Web pages. 

Eric Jul
Workshop Chair 

Workshops

W1: 5th ECOOP Workshop for Doctoral Students in Object-Oriented
    Systems 
W2: Quantitative Methods for Object-Oriented Systems Development
W3: Object Technology: Learning, Teaching and Training
W4: Advances in Metaobject Protocols and Reflection
W5: Experiences with Object-Oriented Design Methods
W6: Use of Object-Oriented Technology for Network Design and
    Management
W7: Pattern Languages of Object-Oriented Programs
W8: Mobility and Replication

-------------------------------------------------------------------------------
Exhibition
----------

The main conference will be accompanied by a three-day commercial
exhibition on August 9, 10 and 11. Vendors of object-oriented products
and services should contact the Exhibition Chair at the earliest
convenience to ensure their inclusion. For further information please
contact: 

Elmer Sandvad
Computer Science Department
University of Aarhus
Ny Munkegade 116, Bldg 540
DK-8000 Aarhus C, Denmark
Telephone: +45 8942 3188
Fax: +45 8942 3255
E-mail: ess@daimi.aau.dk


Demonstrations
--------------
ECOOP'95 provides a venue for live demonstrations of object-oriented
systems. Proposals for demonstrations of object-oriented software are
invited to illustrate innovative concepts or recent work in applying
object-oriented technology. Demonstrations will be selected on the basis
of technical merit, novelty and relevance. Demonstrations include
in-house applications, as well as academic and corporate research
efforts.
If you are planning to present a system at ECOOP'95, please send a
description of the demonstration, your name and address together with
hardware requirements to:

Kurt Nxrmark
Department of Mathematics and Computer Science
Institute for Electronic Systems
Aalborg University
Fredrik Bajers Vej 7E
DK-9220 Aalborg, Denmark
Telephone: +45 9815 8522
Fax: +45 9815 8129
E-mail: normark@iesd.auc.dk

-------------------------------------------------------------------------------
Pricing Information   (all prices are in DKK) 
-------------------

CONFERENCE FEE

         Paid before   Paid before    Paid after      
         June 5, 1995  July 24, 1995  July 24, 1995   
Regular  2550          3000           3450            
Reduced  2100          2550           3000        
Student   900          1350           1800                 

WORKSHOP-only* FEE

Regular  1105          1300           1495            
Reduced   910          1105           1300         
Student   360           585            780                  

TUTORIAL (full day) FEE

Regular  1870          2200           2530            
Reduced  1540          1870           2200        
Student   660           990           1320                 

TUTORIAL (half day) FEE

Regular  1020          1200           1380            
Reduced   840          1020           1200         
Student   360           540            720                

* Please note that workshop participation is free of charge for
  conference participants.

Cancellation
............

Notification of cancellation must be made in writing to Aarhus
Convention Bureau. For cancellation before 5 June 1995, fees will be
fully refunded, except for an administration charge of DKK 300. For
cancellation between 5 June and 24 July, a refund of 50% will be made.
In the event of cancellation after 24 July, fees will not be refunded.
All refunds will be dealt with only after the conference. 


Accommodation Booking
.....................

Category                            DKK per night 
                                      (approx.)   

A. with                 single room     895
   bath/shower/toilet   double room     995   
                                       
B. with                 single room   420-480
   bath/shower/toilet   double room   505-680
                                        
C. primarily without    single room   315-340
   bath/shower/toilet   double room     465

All room prices include breakfast, VAT and service
charges. Payment directly to hotel upon departure. NB!
Should the preferred category be fully booked, we
reserve the right to book you a room in the alternative
category. 

Confirmation will be forwarded. 

Tickets will be handed over on arrival. 

Payment
.......

The payment has to be none in one of the following ways:

   cheque in Danish Crowns, drawn on a Danish bank and made payable
   to: ECOOP'95, c/o Aarhus Convention Bureau, Raadhuset,
   DK-8000 Aarhus C, Denmark 
   bank transfer order to: ECOOP'95, c/o Aarhus Convention
   Bureau. Account No. 3627-3258011031, Den Danske Bank,
   2-12 Holmens Kanal, DK-1092 Copenhagen K, Denmark 
   credit card: Visa, Diners, Eurocard, MasterCard, JCB or
   Dankort 

NB! Fees, if any, are at the sender's expense.

-------------------------------------------------------------------------------
General Information
-------------------

ECOOP'95, the Ninth European Conference on Object-Oriented
Programming, will be held at the University of Aarhus, Denmark. The
ECOOP'95 conference lasts from 7 August to 11 August 1995. The Final
Program and other information including the registration form can be
obtained from: 

ECOOP'95
Dept. of Computer Science
University of Aarhus
Ny Munkegade, Bldg 540
DK-8000 Aarhus C, Denmark
E-mail: ecoop95@daimi.aau.dk
Telephone: +45 8942 3188
Fax: +45 8942 3255
WWW: http://www.daimi.aau.dk/ecoop95

The contact numbers for urgent messages to the ECOOP'95 organization
and conference delegates during the five days of ECOOP'95 will be:

Telephone: +45 8942 3417
Fax: +45 8613 1769

All fax messages should be clearly marked: ECOOP'95. 

Registration 
............

Please fill in the registration and hotel reservation form
and return it along with relevant payment as soon as possible to: 

ECOOP'95
Aarhus Convention Bureau
Raadhuset
DK-8000 Aarhus C, Denmark
Telephone: +45 8612 1177
Fax: +45 8612 0807

This is the address for all correspondence concerning registration and
accommodation (payment, cancellation, etc). 

Registration Fees 
.................

Please consult the registration form for details of the fees. The
deadline for receipt of early registrations 5 June 1995.

The ECOOP'95 registration fee covers: 

   Access to scientific sessions 
   Access to any number of workshops (provided attendance has been
   granted by the workshop organizer) 
   ECOOP'95 Proceedings and other conference materials 
   Welcome Reception and Buffet at Kongreshuset, 9 August 
   Access to Exhibitions 
   Lunches (9-11 August) 
   Refreshments during breaks 
   Local transportation 

The Tutorial registration fee covers:

   Access to the registered tutorials 
   Tutorial materials 
   Refreshments during breaks 
   Local transportation 

The Workshops-only registration fee covers:

   Access to any number of workshops (provided attendance has been
   granted by the workshop organizer) 
   Workshop materials 
   Refreshments during breaks 
   Local transportation 

The Workshops-only registration fee is available to persons who will
participate in one or more workshops, but who will not register for
the conference. Note that no workshop fee applies to persons
registered for the conference. Reduced rates are available for ACM
members only, and only if the correct ACM membership number is
specified on the registration form. Student rates are available for
all full-time students. A student registration must be accompanied by
proof of full-time student status, otherwise it will be returned. 

Accompanying persons are entitled to: 

   attend the Welcome Reception and Buffet. Please note, that tickets
   are required. Remember to indicate the number of tickets on the
   registration form. 
   visit the Exhibition 

Lunch tickets for lunches on 7-8 August should be ordered on the
registration form. 

Payment 
.......

All payments should be forwarded in Danish currency (DKK) and can be
made by bank transfer, Eurocheque (each cheque not exceeding DKK
1,500), cheque (drawn on a Danish bank), postal cheque, or credit card
(Dankort, Eurocard, Master Card, Visa, JCB, Diners). All fees are on
the account of the participant. When paying by credit card, it is
necessary to state the card number and date of expiry, and the
card-holder's name exactly as shown on the card. Please note that it
will not be possible to pay fees by credit card during the conference.
Upon receipt of the registration fee, each participant will receive
confirmation of the accommodation booked and a receipt for the amount
paid. Please bring this confirmation with you and present it at the
registration desk when collecting your tickets and materials. 

Cancellation 
............

Notification of cancellation must be made in writing to Erhus
Convention Bureau. For cancellation before 5 June 1995, fees will be
fully refunded, except for an administration charge of DKK 300. For
cancellation between 5 June and 24 July, a refund of 50% will be made.
In the event of cancellation after 24 July, fees will not be refunded.

Insurance 
.........

You are requested to arrange for your own health and travel insurance.
The ECOOP'95 Organizing Committee will not accept responsibility for
compensation as regard of accidents or damage suffered by participants
and accompanying persons, occurring during or arising from the
conference. 

Social Program 
..............

 + Welcome Reception and Buffet
   A reception and buffet will be hosted by the Mayor of Erhus on 9
   August, at Kongreshuset. The reception and buffet is open to all
   registered conference delegates and accompanying persons. Please do
   not forget to register for the reception on the registration form.

 + Banquet
   The conference banquet will be held on 10 August, at the Varna
   Mansion in the outskirts of Erhus. Participation is not included in
   the conference fee, so bear in mind to register for the banquet on
   the registration form.

Accommodation 
.............

Hotels 

Erhus Convention Bureau has made preliminary hotel reservations for
the ECOOP'95 participants. Please use the enclosed registration form
to book rooms. The hotels have been divided into two categories
according to standard of comfort. The organisers cannot guarantee
accommodation to participants who do not book in advance. Payment has
to be made directly to the hotel upon departure. 

Camp sites and summer cottages 

If you wish to stay at a camp site or summer cottage during the
conference, please contact: 

   Camping Blommehaven
   Xrneredevej 35, DK-8270 Hxjbjerg
   Telephone: +45 8627 0207
   Fax: +45 8627 4522
   Beautifully located by the sea in the Marselisborg Woods close to
   the city centre. 
   Cabins available. Approx. 20 min. by bus from conference venue. 

   Ajstrup Camping
   Ajstrup Strandvej, DK-8340 Malling
   Telephone: +45 8693 3535
   Fax: +45 8693 1584
   Situated south of Erhus in recreational surroundings by the beach
   and close to the woods. Cabins available. Approx. 50 min. by bus,
   30 min. by car from conference venue. 

   Dansommer
   Voldbjergvej 12, DK-8240 Risskov
   Telephone: +45 8617 6122
   Fax: +45 8617 6855
   For booking of summer cottages. 

Climate 
.......

The weather in Denmark in August is usually sunny with temperatures
around twenty degrees celsius, and with occasional showers. 

Travel 
......

Erhus Airport/Tirstrup offers direct flights to and from Copenhagen,
Oslo, Stockholm, London, Gothenburg, and Brussels. The airport bus,
with service to and from the central train station, departs from the
airport directly after each arriving flight; it leaves for the airport
from the train station 70 minutes before all departing domestic
flights (i.e., to Copenhagen) and 80 minutes before all departing
direct international flights. Erhus is served by a train station with
an hourly comfortable service to and from Copenhagen (4 1/2 hours) and
several connections daily with Sweden, Germany, and the rest of
Europe. There is also a harbour conveniently located in the centre of
the city, with ferry and hydrofoil connections with Copenhagen via
Kalundborg. A motorway links Erhus directly with Germany and thereby
most major European cities. Erhus is a 4 to 5 hour drive from Hamburg.
Within the city, the municipal bus system is a convenient and reliable
means of transportation. Each ECOOP'95 participant will be issued with
a bus card covering local bus transportation. 

-------------------------------------------------------------------------------
Organization
------------

ECOOP'95 is organized by the Department of Computer Science,
University of Aarhus and AITO (Association Internationale pour les
Technologies Objets) in cooperation with ACM/SIGPLAN. 

Executive Committee 
...................

Conference Chair: Ole Lehrmann Madsen (University of Aarhus)
Program Chair: Walter Olthoff (DFKI GmbH)
Organizing Chair: Jxrgen Lindskov Knudsen (University of Aarhus)
Tutorial Chair: Birger Mxller-Pedersen (Norwegian Computing Center)
Workshop Chair: Eric Jul (University of Copenhagen)
Panel Chair: Boris Magnusson (Lund University)
Demonstrations Chair: Kurt Nxrmark (Aalborg University)
Exhibition Chair: Elmer Sandvad (University of Aarhus)

Conference Secretariat 
......................

Susanne Brxndberg (University of Aarhus)
Janne Damgaard (University of Aarhus)
Marianne D. Iversen (University of Aarhus)

Program Committee 
.................

Mehmet Aksit (University of Twente)
Pierre America (Philips)
Jean Bezivin (University de Nantes)
Pierre Cointe (Ecoles des Mines de Nantes)
Bjxrn Freeman-Benson (Carleton University)
Yutaka Ishikawa (RWCP)
Gerti Kappel (University of Linz)
Eric Jul (University of Copenhagen)
Mary Loomis (Hewlett-Packard)
Boris Magnusson (Lund University)
Jose Meseguer (SRI)
Paola Mello (University of Bologna)
Bertrand Meyer (ISE)
Oscar Nierstrasz (University of Bern)
Walter Olthoff (DFKI GmbH)
Andreas Paepcke (Xerox PARC)
Jens Palsberg (University of Aarhus)
Remo Pareschi (Xerox, France)
Markku Sakkinen (University of Jyvdskyld)
Alan Snyder (SunSoft, Inc.)
Dave Thomas (Object Technology International)
Mario Tokoro (Keio University/Sony CSL)
Peter Wegner (Brown University)
Roberto Zicari (Goethe-University)

Sponsoring Organizations 
........................

ACM/SIGPLAN: Association of Computing Machinery : Special Interest
Group in Programming Languages
AITO: Association Internationale pour les Technologies Objets
CINCOM Systems, Denmark
DAIMI: Department of Computer Science, University of Aarhus, Denmark
Den Danske Bank, Denmark
DEVISE: Centre for Experimental System Development, University of
Aarhus, Denmark
Faculty of Science, University of Aarhus, Denmark
Sun Division, ICL Data A/S, Denmark




======================================================================= 92 ===
Date:    26 Apr 1995 19:03:51 GMT
From:    ryan@ponder.csci.unt.edu (Ryan Stansifer)
Subject: a checkbox in VBTKit/Trestle




How do you correctly implement a checkbox in VBTKit/Trestle?  I am
working along the following lines:

VAR
    (*  the interior of the button *)
    text   := TextVBT.New(" Check ");
    v      := RigidVBT.FromHV (text, 20.0, 10.0);

    (*  3-d shadow around the interior *)
    sfb    := NEW(ShadowedFeedbackVBT.T).init(ch:=v, shadow:=sh);

    (*  put a check box off to the side *)
    mfb    := MarginFeedbackVBT.NewBox(ch:=sfb);

    (*
    Without something like BiFeedbackVBT the shadow around "v" is
    not altered when the button is pushed.

    But I don't understand BiFeedbackVBT and the arguments to
    BiFeedbackVBT.T init
    *)

    (* the button *)
    switch := NEW(SwitchVBT.T).init(mfb?????);

    (* add the boolean state, and we are done *)
    main   := NEW(BooleanVBT.T, callback:=Check).init(switch);


Ryan Stansifer
ryan@cs.unt.edu






======================================================================= 93 ===
Date:    26 Apr 1995 19:13:18 -0400
From:    bm@news.cs.columbia.edu (Blair MacIntyre)
Subject: modula3 tutorial ...



I have an online modula3 tutorial in html another student in the lab
ftp'd from .... ??? .... he can't remember!  

He had gotten the pointer from the newsgroup, which I remember seeing
as well.  

Will the author please tell us who you are, and were we got it?  We'd
like a tex or postscript version to give to people new to the
language, but we only have the html version!

Besides, we'd like to put a link in to your home page and give you
credit for it. :-)

Thanks!


======================================================================= 94 ===
Date:    Thu, 27 Apr 1995 02:55:11 GMT
From:    fmc@world.std.com (Fraser M Campbell)
Subject: Re: Does anyone know where.. COMPLETE src for Linux? m3

drake@PROBLEM_WITH_INEWS_DOMAIN_FILE (Joshua Drake) writes:

>I am looking for the complete src tree for modula-3, for linux. The one on 
>sunsite seems to be missing some very important things.. (like the makefile).
>If anyone can direct me please let me know via e-mail.
>					drake@transport.com

The pre-built Linux binaries are available from  ftp.vlsi.polymtl.ca in
/pub/m3/linux.

Source code is available at gatekeeper.dec.com in
/pub/DEC/Modula-3/release-3.3

Hope that helps ...


======================================================================= 95 ===
Date:    Thu, 27 Apr 95 23:42:29 GMT
From:    pjt2@ukc.ac.uk (Paul Teasdel)
Subject: Help with Linux modula3 compiler

I've just installed the SRC modula3 compiler for Linux.  When I try
to run a program ie tetris it comes up with the following error:

tetris:  can't find library 'libm3X11R4.so.3'

I can find the library in /usr/local/soft/modula3-3.4/lib/m3/pkg so
I know it's there.  How do I solve the problem.  Do I need to do
some recompiling os somehow tell my machine to look in the right
place.

Cheers

Paul



======================================================================= 96 ===
Date:    Fri, 28 Apr 1995 08:31:40 -0400
From:    gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS)
Subject: Help with Linux modula3 compiler

Paul Teasdel writes:
 > I've just installed the SRC modula3 compiler for Linux.  When I try
 > to run a program ie tetris it comes up with the following error:
 > 
 > tetris:  can't find library 'libm3X11R4.so.3'
 > 
 > I can find the library in /usr/local/soft/modula3-3.4/lib/m3/pkg so
 > I know it's there.  How do I solve the problem.  Do I need to do
 > some recompiling os somehow tell my machine to look in the right
 > place.
 > 
 > Cheers
 > 
 > Paul
 > 

Easily solved: setenv LD_LIBRARY_PATH /usr/local/soft/modula3-3.4/lib/m3/LINUX
		(assuming csh)

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

2 Elizabeth Drive
Chelmsford, Ma.
01824


======================================================================= 97 ===
Date:    28 Apr 1995 08:14:41 GMT
From:    rrw1000@cus.cam.ac.uk (Richard Watts)
Subject: Re: Help with Linux modula3 compiler

In article <9705@merlin.ukc.ac.uk>, Paul Teasdel <pjt2@ukc.ac.uk> wrote:
>I've just installed the SRC modula3 compiler for Linux.  When I try
>to run a program ie tetris it comes up with the following error:
>
>tetris:  can't find library 'libm3X11R4.so.3'
>
>I can find the library in /usr/local/soft/modula3-3.4/lib/m3/pkg so
>I know it's there.  How do I solve the problem.  Do I need to do
>some recompiling os somehow tell my machine to look in the right
>place.

 ld.so has to be able to find the library in one of :

(i) /etc/ld.so.conf
(ii) LD_LIBRARY_PATH

 I generally symlink all the shared libs to a `lib' directory somewhere,
and then add that to /etc/ld.so.conf. In fact, I believe the current
distribution generates symlinks for you ?

 (remember to re-run `ldconfig' if you change /etc/ld.so.conf).


Richard.
-- 
`The past tempts us; the present confuses us; the future frightens us -  and
our lives slip away moment by moment - lost in that vast, terrible inbetween'
                                                       (Babylon 5)
The University of Cambridge can't have these opinions even if it wants them.


======================================================================= 98 ===
Date:    Fri, 28 Apr 1995 01:41:51 GMT
From:    beatty@beatty.slip.netcom.com (Derek Beatty)
Subject: Modula-3 partial solution

Recently I posted a query re: building SRC Modula-3 release 3.5.2 on a  
NeXTstation running NEXTSTEP 3.2.  The symptom was that on large  
compilations the compiler would die.  

The problem, it turns out, was that it was running out of memory: the   
Modula-3 runtime calls sbrk to allocate large chunks of memory, and NeXT's  
undocumented sbrk emulation is only good to 6MB.  Fortunately, Modula-3  
does not care if its memory chunks are contiguous, so writing my own sbrk  
as a simple wrapper around vm_allocate sufficed.  I've succeeded in  
building Trestle.

However, I haven't succeeded in building Trestle applications---there's no  
shared memory in the Mouse-X libraries on the NeXT archives.  It looks  
like a dummy version of XSharedMem is called for.  This much I think I've  
figured out:
PROCEDURE UsesExtension (st: VBT.ScreenType): BOOLEAN =
    BEGIN 
    RETURN FALSE; 
    END UsesExtension;

--
Derek Lee Beatty
beatty@netcom.com     ,(((|)))-K    ,(((|)))-K    ,(((|)))-K
Austin, Texas           ^   ^         ^   ^         ^   ^   


======================================================================= 99 ===
Date:    Fri, 28 Apr 95 14:24:45 -0700
From:    mhb@pa.dec.com ("Marc H. Brown")
Subject: Re: a checkbox in VBTKit/Trestle


I suggest that you use FormsVBT.

But if you want to do it yourself, the following
code should work;

    child := TextVBT.New("check");
    feedback := MarginFeedbackVBT.NewBox(child, state.shadow)
    switch := NEW(SwitchVBT.T).init(feedback)
    main   := NEW(BooleanVBT.T, callback:=Check).init(switch);    
    BooleanVBT.Put(main, TRUE);
    


======================================================================= 100 ===
Date:    28 Apr 1995 23:39:33 GMT
From:    pbm1001@cam.ac.uk (Paul Menage)
Subject: Obtaining return address of procedure

Is there any standard way of obtaining the return address of the
executing procedure ( or any other address within the calling
procedure) , to enable a procedure ( in this case an execution tracing
package ) obtain the name of the calling procedure with a call to
RTProcedureSRC.FromPC() ? 

I can do it by counting down the stack from the address of a local
variable by a fixed amount, but the fixed amount can only be obtained
by trial and error, and has a habit of changing when the code in the
procedure changes. Also, this method strikes me as a little
non-portable...

Thanks,

Paul

-- 
Paul Menage        Magdalene College, Cambridge      pbm1001@cam.ac.uk
'One of its satellites, a green and insignificant planet, is now dead'


======================================================================= 101 ===
Date:    Fri, 28 Apr 1995 13:26:00 -0700
From:    bruce@newton.apple.com (Bruce Thompson)
Subject: Re: Help with Linux modula3 compiler

In article <9705@merlin.ukc.ac.uk>, pjt2@ukc.ac.uk (Paul Teasdel) wrote:

> I've just installed the SRC modula3 compiler for Linux.  When I try
> to run a program ie tetris it comes up with the following error:
> 
> tetris:  can't find library 'libm3X11R4.so.3'
> 
> I can find the library in /usr/local/soft/modula3-3.4/lib/m3/pkg so
> I know it's there.  How do I solve the problem.  Do I need to do
> some recompiling os somehow tell my machine to look in the right
> place.
> 
> Cheers
> 
> Paul
Is your LD_LIBRARY_PATH variable set correctly?

Assuming you use bash, try this:

  $ LD_LIBRARY_PATH=/usr/local/soft/modula3-3.4/lib/m3/LINUX
  $ export LD_LIBRARY_PATH

Or using tcsh:

  % setenv LD_LIBRARY_PATH /usr/local/soft/modula3-3.4/lib/m3/LINUX

Either that or setup your ld.config to include the modula 3 libraries.

   Cheers,
   Bruce

-- 
--------------------------------------------------------------------
Bruce Thompson                  | "Never put off till tomorrow what
PIE Developer Information Group |  you can comfortably put off till
Apple Computer Inc.             |  next week."
                                |    -- Unknown
Usual Disclaimers Apply         |


======================================================================= 102 ===
Date:    Fri, 28 Apr 95 21:22:23 GMT
From:    pjt2@ukc.ac.uk (Paul Teasdel)
Subject: Re: Help with Linux modula3 compiler

Thanks to the many people who offered help to the last problem.
This seems to be the general solution:

  put the library directories in /etc/ld.so.config and then run
  /sbin/ldconfig -v

That solves the problems with finding the libraries I have
installed.  Now when I run tetris I get this:

tetris: can't find library 'libXaw.so.6'

The only relevant library I have is /usr/X11/lib/libXaw.so.3.1.0 so
it seems like I need to get some newer libraries.  Where do I find
them and is it an easy process to install them?

Cheers

Paul



======================================================================= 103 ===
Date:    29 Apr 1995 20:21:19 GMT
From:    rbrewer@rwb114.rh.psu.edu (Robert W. Brewer)
Subject: Re: Help with Linux modula3 compiler

Yes, you need XFree86 3.1.1.  It looks like you have 2.x installed
right now.  

<URL:ftp://sunsite.unc.edu/pub/Linux/>

-Rob
-- 
Robert W. Brewer KB3BEH   A thorough knowledge of the Bible is worth more
rbrewer@psu.edu           than a college education.  --Theodore Roosevelt


======================================================================= 104 ===
Date:    29 Apr 1995 23:15:22 GMT
From:    tlh20@thor.cam.ac.uk (T.L. Harris)
Subject: accessing a variable before initialising it

Looking at the Modula-3 language definition, I was wondering if there is
a reason why it is legal to access a variable before initiallising it. To me
this seems somewhat at odds with other features of the language which
generally seem to reduce opportunities for 'careless' errors along the lines
of not freeing memory that is no longer pointed to, or forcing non-sensible
typecasts.

I can see circumstances where an problem of this type could not be identified 
at compile time - e.g. with INTEGERs a and x:

IF a=1 THEN x=1; END;
x=x+1;

may fail if x is initially undefined and a#1, but succeed whatever x's
initial state if a=1. This would, admittedly, produce some overhead at
run-time - but there have been numerous times when some combination of
circumstances has left a variable undefined and led to unpredictable
consequences.

Any thoughts?

tim

--
+---------------------------------------------------------------------------+
|  You remind me of Shallot, only made of shadows even though you're not -  |
|                                           Indigo Girls, Left me a Fool    |
+----------------------------+----------------------------------------------+
| tlh20@cam.ac.uk            | WWW home page:                               |
|                            | http://www.chu.cam.ac.uk/home/tlh20/home.html|
+----------------------------+----------------------------------------------+



======================================================================= 105 ===
Date:    Sun, 30 Apr 1995 12:42:39 -0700
From:    bruce@newton.apple.com (Bruce Thompson)
Subject: Re: Help with Linux modula3 compiler

In article <9718@merlin.ukc.ac.uk>, pjt2@ukc.ac.uk (Paul Teasdel) wrote:

> Thanks to the many people who offered help to the last problem.
> This seems to be the general solution:
> 
>   put the library directories in /etc/ld.so.config and then run
>   /sbin/ldconfig -v
> 
> That solves the problems with finding the libraries I have
> installed.  Now when I run tetris I get this:
> 
> tetris: can't find library 'libXaw.so.6'
> 
> The only relevant library I have is /usr/X11/lib/libXaw.so.3.1.0 so
> it seems like I need to get some newer libraries.  Where do I find
> them and is it an easy process to install them?
> 
> Cheers
> 
> Paul
Hi.
    It just doesn't want to cooperate does it! :-) Ok, I'd suggest you grab the
 latest X11R6 from sunsite.unc.edu:/pub/Linux/X11/XFree86-3.1.1 and install tha
t. There's a large amount of stuff there, but as I recall there's an INSTALL fi
le that will walk you through the installation. It's not difficult at all.

   Cheers,
   Bruce.
-- 
-----------------------------------------------------------------------
Bruce Thompson                     | "Never put off till tomorrow what
Newton Developer Information Group |  you can comfortably put off till
Apple Computer Inc.                |  next week."
                                   |    -- Unknown
Usual Disclaimers Apply            |


======================================================================= 106 ===
Date:    28 Apr 1995 17:49:00 GMT
From:    buzz@marvin.isdn.cs.tu-berlin.de (Bastian Schlueter)
Subject: Re: Modula-3 partial solution

beatty@beatty.slip.netcom.com (Derek Beatty) wrote:

Hello Derek,

[...]
>The problem, it turns out, was that it was running out of memory: the   
>Modula-3 runtime calls sbrk to allocate large chunks of memory, and NeXT's  
>undocumented sbrk emulation is only good to 6MB.  Fortunately, Modula-3  

are you shure about that? The following output makes me wonder:

marvin buzz 102 (Documentation/RFC):limit
cputime         unlimited
filesize        unlimited
datasize        6144 kbytes  <--- Looks like this made sbrk fail ?!
stacksize       512 kbytes
coredumpsize    unlimited
memoryuse       unlimited

No i don't have any limit set by myself, nor by my sysop (that's me of course :
-)

Greetings
          Bastian
--
 Bastian Schlueter              TEL.: +49 030 / 314 25 973  (uni)   
 Fehrbellinerstr. 39                            44 34 01 35 (priv)   __o
 D-10119 Berlin         e-mail: buzz@cs.TU-Berlin.DE               _`\<,_
 Germany                        buzz@marvin.isdn.cs.TU-Berlin.DE  (_)/ (_)
  -- Radfahrer haben nichts zu verlieren als ihre Ketten --     ~~~~~~~~~~~



======================================================================= 107 ===
Date:    Sun, 30 Apr 1995 13:20:22 GMT
From:    beatty@beatty.slip.netcom.com (Derek Beatty)
Subject: Re: Modula-3 partial solution

In article <3nr9qd$7dr@marvin.isdn.cs.tu-berlin.de>  
buzz@marvin.isdn.cs.tu-berlin.de (Bastian Schlueter) writes:
> beatty@beatty.slip.netcom.com (Derek Beatty) wrote:
> >The problem, it turns out, was that it was running out of memory: the   
> >Modula-3 runtime calls sbrk to allocate large chunks of memory, and  
NeXT's  
> >undocumented sbrk emulation is only good to 6MB.  Fortunately, Modula-3  
> 
> are you shure about that? The following output makes me wonder:
> . . .

No, I'm absolutely sure.  I raised all the limits before I ran the
compiler, and it still failed.  I attached the debugger
to the compiler process, set a breakpoint at sbrk, and watched the
parameters and the return values.  It's only a coincidence that the
default process data size limit is also the point of failure.  Here are  
the notes I kept during the debugging process:

Tried ulimit -d 20000; still failed at same spot
Tried ulimit -s 2000 as well; still failed at same spot
Ran m3build, paused, attached debugger to m3 process.  Found that it dies  
on
attempt to access memory at 0x5bc000 (inaccessible).  Previous longword is  
accessible.  Somehow, Mach didn't give M3 the memory it wanted:
Breakpoint 1, 0x5055714 in sbrk ()
(gdb) p/x $d0
$17 = 0xcc000
(gdb) fin
Run till exit from #0  0x5055714 in sbrk ()
0xdec4c in RTOS__GetMemory ()
(gdb) p/x $d0
$18 = 0x5aa000
(gdb) cont
Continuing.
Program generated(1): Memory access exception on address 0x5bc000 (invalid  
address).
0x5008622 in memcpy ()
(gdb)
Trying m3build from a csh with limit data unl;limit stack 32768...same  
error.
My best guess is now that the sbrk() function doesn't really work.  I  
should
try writing my own, a wrapper on vm_allocate.



--
Derek Lee Beatty
beatty@netcom.com     ,(((|)))-K    ,(((|)))-K    ,(((|)))-K
Austin, Texas           ^   ^         ^   ^         ^   ^   


======================================================================= 108 ===
Date:    30 Apr 1995 03:12:42 GMT
From:    davidf@cais3.cais.com (David R Fruehwald)
Subject: Re: Modula3 and Oberon2

I would be interested how do I get it.


