======================================================================= 1 ===
Date:    Mon, 02 May 94 15:11:53 -0700
From:    mhb@src.dec.com ("Marc H. Brown")
Subject: Re: formsedit and "Visual" windowing


    > It appears that Browse requires the items be listed or from a file
    > (not from an array of Text.T). 
    
I suggest you use the "realize" method to subclass the ListVBT that 
Browser uses, and then call ListVBT methods directly using your array 
of Text.T. Look at the section in FormsVBT.i3 file entitled "Sublcass 
of components"; the example there is pretty explicit. 

       
    > On another point, while formsedit is much better than building windows by
    > writing code, it seems what would make life much better would be to have
    > a graphical tool which one could pick various forms, place them on the wi
ndow
    > expand them, change characteristics of them.  The result of this tool wou
ld
    > be the FormsVBT language which describes the window just built.  Anyone
    > working on this kind of thing?

Nobody that I know of. However, last summer, an intern Krishna Bharat 
from Georgia Tech, wrote an system "Visual Obliq" that includes a 
direct-manipulation GUI-builder. That can be used for generating 
.fv files, but it's very preliminary at present. 


======================================================================= 2 ===
Date:    Tue, 3 May 1994 13:54:14 GMT
From:    mmeola@cahill (Vulcan)
Subject: Using the Xt interface...

Has anyone had success using the X interfaces?  In this code,

PROCEDURE uiInit(argc:INTEGER; argv:M3toC.Argv) =
  BEGIN
    Top := Xt.AppInitialize(AppC, "Xtimeclock",
                            NIL, 0,       (* options *)
                            argc, argv);  (* user-supplied args *)
    Xt.GetApplicationResources(Top, ADR(global_data),
                               rezs, 2);
  END uiInit;

I get this error:

m3make
/work/m3/bin/m3 -w3 -make -why -g    -o timeclock -F.PGM_SOURCES 
new source -> compiling ./Ui.m3
"./Ui.m3", line 26: incompatible types (application_class)
1 error encountered

application_class is "Xtimeclock" -- what do I need to do to get this
to compile?

--
Matt Meola
mmeola@lookout.ecte.uswc.uswest.com



======================================================================= 3 ===
Date:    3 May 1994 14:55:07 GMT
From:    kalsow@src.dec.com (Bill Kalsow)
Subject: Re: Local procedure-constant as parameter

In article <2q5lcgINN3dp@fstgds15.tu-graz.ac.at>, laszlo@post.ifi.uni-klu.ac.at
 (Laszlo BOESZOERMENYI) writes:
> Modula-3 explicitly forbids to assign a local (nested) procedure
> to a procedure variable (this is o.k., otherwise 
> a procedure could be called without context).
> The compiler allows, however, to pass a local procedure as parameter.
> I wonder, whether this is a feature or a bug?!

It's a feature.  See SPwM3.

Section 2.3.1, Assignment:

   Since there is no way to determine statically whether the value
   of a procedure parameter is local or global, assigning a local
   procedure is a runtime rather than static error.

Section 2.3.2, Procedure call:

   For a READONLY or VALUE parameter, the actual can be any expression
   assignable to the type of the formal (except that the prohibition
   against assigning local procedures is relaxed).

 - Bill Kalsow



======================================================================= 4 ===
Date:    3 May 1994 17:06:45 GMT
From:    kalsow@src.dec.com (Bill Kalsow)
Subject: Re: Using the Xt interface...

In article <Cp8ByE.Mt1@da_vinci.it.uswc.uswest.com>, mmeola@cahill (Vulcan) wri
tes:

>     Top := Xt.AppInitialize(AppC, "Xtimeclock", ...

> "./Ui.m3", line 26: incompatible types (application_class)

> application_class is "Xtimeclock" -- what do I need to do to get this
> to compile?

Try

     IMPORT M3toC;
 
     Top := Xt.AppInitialize(AppC, M3toC.TtoS ("Xtimeclock"), ...

 - Bill Kalsow




======================================================================= 5 ===
Date:    3 May 1994 16:08:33 GMT
From:    pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
Subject: Re: Local procedure-constant as parameter


>Modula-3 explicitly forbids to assign a local (nested) procedure
>to a procedure variable (this is o.k., otherwise 
>a procedure could be called without context).
>The compiler allows, however, to pass a local procedure as parameter.
>I wonder, whether this is a feature or a bug?!
>

It's a feature. The language report says (section 2.2.8):
"A local procedure can be passed as a parameter but not assigned,
since in a stack implementation a local procedure becomes invalid
when the frame for the procedure containing it is popped."

Or, in other words, it is generally no problem to pass a procedure
as a parameter because - during the execution of the called procedure -
the context of the caller is "alive" and may be used by the nested
procedure.

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




======================================================================= 6 ===
Date:    3 May 1994 13:59:44 GMT
From:    laszlo@post.ifi.uni-klu.ac.at (Laszlo BOESZOERMENYI)
Subject: Local procedure-constant as parameter

Modula-3 explicitly forbids to assign a local (nested) procedure
to a procedure variable (this is o.k., otherwise 
a procedure could be called without context).
The compiler allows, however, to pass a local procedure as parameter.
I wonder, whether this is a feature or a bug?!

Please find the following example with comments.

Best regards
Laszlo Boszormenyi

MODULE x EXPORTS Main;

  IMPORT SIO;

  TYPE
    Action    =  PROCEDURE (i: INTEGER);
  VAR aa: Action;


  PROCEDURE P(a: Action) =
  BEGIN
    a(1);  (*This is compiled and runs properly*)
    aa:= a; (*This is compiled and crahses at runtime (feature or bug?)*)
  END P;

  PROCEDURE Q() =

   
    PROCEDURE A(i: INTEGER) =
    BEGIN 
      SIO.PutInt(i); SIO.Nl();
    END A;

  BEGIN
    (*aa:= A; This is not compiled: in accordance with the definition*)
    P(A);  (*This is compiled and runs properly. Is this allowed?*)
  END Q;

BEGIN
  Q();
END x.


*********************************
* Prof. Laszlo Boeszoermenyi	*
* Institut fuer Informatik	*
*                              	*
* Universitaet Klagenfurt	*
* Universitaetsstr. 65-67  	*
* A-9022 Klagenfurt / Austria	*
*                              	*
* e-mail:			*
* laszlo@ifi.uni-klu.ac.at	*
* Tel.: 			*	
* 00-43-463-2700-509 		*
* 00-43-463-2700-506 (secr.)	*
* Fax.:		 		*
* 00-43-463-2700-505 		*
*********************************



======================================================================= 7 ===
Date:    3 May 1994 11:40:27 GMT
From:    a.vermeulen@ecn.nl (Alex T. Vermeulen)
Subject: Re: OS/2 2.x port of SRC Modula-3 attempt

In <CozI04.DpC@undergrad.math.uwaterloo.ca>, bcrwhims@undergrad.math.uwaterloo.
ca (Carsten Whimster) writes:
>Hi all,
>
>I am going to attempt a port of SRC modula-3 3.1 starting with the
>SRC package available for Linux. I am not an experienced "porter",
>so I would appreciate it if anyone more familiar with OS/2 and
>porting could assist me. I am willing to do most of the work, but
>probably not knowledgeable enough to do all of it.
>
>I am starting tonight, with what little help the documentation gives,
>and see where that lands me. I will probably try using emx 0.8h, as
>I have heard that this is the best package for porting UNIX software
>to OS/2. Any comments/suggestions?
>
>Thanks to anyone who replies. (e-mail or news is fine).
>
I wish you good luck and would like to hear when you make any progress.
I started on the alpha 3.0 release with emx 0.8g and the Linux sources
and compilation of the core went reasonably well. However compiling
m3lib was not possible with my limited amount of time. I started on
porting 3.1 but after trying for two hours I realized I would not have
the time to continue. I used a PD-cshell port to execute the scripts, but
have forgotten which. I also used gnumake as the make-program, but
the newest OS/2-version (forgot the number) is very picky with spaces
or tabs inside makefiles and chokes on spaces so I wined and got to
more urgent other jobs. You will need ports of awk, sed, ar and other
gnu/unix utilities to complete the job, but I think it will be possible
to come up with a multi-threaded 32-bits compiler with a estimated working
time of 2-3 weeks.

======================================================================
A.T. Vermeulen (Internet: a.vermeulen@ecn.nl; Phone: (+31)22464194)
Energy Research Foundation, PO Box 1, 1755 ZG  Petten, The Netherlands




======================================================================= 8 ===
Date:    Tue, 3 May 1994 19:07:38 GMT
From:    mmeola@cahill (Vulcan)
Subject: Re: Using the Xt interface...

Bill Kalsow (kalsow@src.dec.com) wrote in comp.lang.modula3 on 3 May 1994 17:06
:45 GMT:

>Try

>     IMPORT M3toC;
> 
>     Top := Xt.AppInitialize(AppC, M3toC.TtoS ("Xtimeclock"), ...

> - Bill Kalsow

Thank you Bill, that worked!  However, now I get complaints during
linking, something like "missing compiled interface Xt.io..."  Any
ideas?



--
Matt Meola


======================================================================= 9 ===
Date:    4 May 1994 20:56:59 GMT
From:    stellanl@vaxkab.e.kth.se (Stellan Lagerstroem)
Subject: Problem building M3-3.1 on ALPHA_OSF


While building 3.1 on a DEC 3000-800 with OSF-1,
during the building of libm3,
the C compiler complains about the following piece of 'RTExceptionC.c':

/* PROCEDURE CurrentFrame (VAR(*OUT*) f: Frame)
 * returns the frame that corresponds to its caller. */

void RTException__CurFrame (Frame *f)
{
  f->lock = FrameLock;
  setjmp (& f->cxt);
  __exc_virtual_unwind (0, &(f->cxt));
  f->pc = f->cxt.sc_pc;
  f->sp = f->cxt.sc_sp;	/* <------- sc_sp UNDEFINED!!!   */
  if (f->lock != FrameLock) abort ();
}

because 'ctx' is a 'sigcontext' which is declared by /usr/include/signal.h as:

struct  sigcontext {
#ifdef  __alpha
	/*
	 *  Backward compatibility -- correlates with user space
	 *  notion of layout.
	 */
	long    sc_onstack;		/* sigstack state to restore */
	long    sc_mask;		/* signal mask to restore */
#else
        int     sc_onstack;             /* sigstack state to restore */
        int     sc_mask;                /* signal mask to restore */
#endif /* __alpha */

/* other architectures here */

#ifdef  __alpha
	long	sc_pc;			/* pc at time of signal */
	long	sc_ps;			/* psl to retore */
	long	sc_regs[32];		/* processor regs 0 to 31 */
	long	sc_ownedfp;		/* fp has been used */
	long	sc_fpregs[32];		/* fp regs 0 to 31 */
	unsigned long sc_fpcr;		/* floating point control register */
	unsigned long sc_fp_control;	/* software fpcr */
	/*
	 * END OF REGION THAT MUST AGREE WITH jmp_buf REGION IN setjmp.h
	 */
	long sc_reserved1;		/* reserved for user */
	long sc_reserved2;		/* reserved for user */
	long sc_reserved3;		/* reserved for user */
	long sc_reserved4;		/* reserved for user */
	unsigned long sc_traparg_a0;	/* a0 argument to trap on exception */
	unsigned long sc_traparg_a1;	/* a1 argument to trap on exception */
	unsigned long sc_traparg_a2;	/* a2 argument to trap on exception */
	unsigned long sc_fp_trap_pc;	/* imprecise pc  */
	unsigned long sc_fp_trigger_sum; /* Exception summary at trigger pc */
	unsigned long sc_fp_trigger_inst; /* Instruction at trigger pc */
#endif  /* __alpha */
};

which seems to lack any 'sc_sp'...

I would be very grateful if anyone could tell me what to believe.

Stellan

--- Stellan Lagerstrom, VMS system manager, School of E.E.
--- Royal Institute of Technology, Stockholm, Sweden


======================================================================= 10 ===
Date:    4 May 1994 22:09:19 GMT
From:    kalsow@src.dec.com (Bill Kalsow)
Subject: Re: Problem building M3-3.1 on ALPHA_OSF

In article <2q926r$m97@news.kth.se>, stellanl@vaxkab.e.kth.se (Stellan Lagerstr
oem) writes:
> 
> While building 3.1 on a DEC 3000-800 with OSF-1,
> during the building of libm3,
> the C compiler complains about the following piece of 'RTExceptionC.c':

>   f->sp = f->cxt.sc_sp;	/* <------- sc_sp UNDEFINED!!!   */


The fix is to include

   #define sc_sp  sc_regs[30]

near the top of RTExceptionC.c.  We built and tested the
Alpha code on an internal version of OSF.  Apparently
the version shipping to customers doesn't define sc_sp.

  - Bill Kalsow



======================================================================= 11 ===
Date:    7 May 1994 07:01:50 GMT
From:    jont@ocs.mq.edu.au (Jonathon Earnshaw TIDSWELL)
Subject: Modula 3 and Windows NT ?

I read the monthly posting in comp.compilers, only the entry for modula-3 seems
not to have been updated since '92. [ Version 2.11 ]

I believe the latest version is 3.1, and that there is a NT port (in progress?)
for version 3.x. 

Can somebody provide more [authorative] detail ?

thanks
- JonT
 
---
Jonathon Earnshaw Tidswell

Postgraduate Student, Department of Computing
School of Mathematics, Physics, Computing and Engineering
Macquarie University, NSW Australia 2039
Phone: +61 2 850 9507    Fax: +61 2 850 9551    Internet: jont@mpce.mq.edu.au
---
Research Fellow
Microsoft Institute of Advanced Software Technology
65 Epping Road North Ryde NSW Australia 2062
Phone: +61 2 870 2776    Fax: +61 2 870 2255    Internet: t-jont@microsoft.com
---
Disclaimer: I think my thoughts are my own, and I believe my writings are too.
"These are my opinions, others may have similar ones, but these are MINE."



======================================================================= 12 ===
Date:    09 May 1994 23:27:35 GMT
From:    connolly@ulua.hal.com (Dan Connolly)
Subject: Non-deterministic Error Conditions?


I was distrurbed to discover that the SRC implementation of Modula-3
doesn't convert checked runtime errors to exceptions, but programs
that generate runtime errors aren't correct anyway...

But what happens when the heap is exhausted? In ANSI C, malloc() may
return NULL, indicating that there's no more memory to be malloc'd (at
least temporarily). I didn't see any corresponding error/exception in
SPwM3 -- NEW() seems to draw from a limitless source of virtual
memory.

But we all know that eventually, memory runs out. I gather that
SRC Modula-3 programs crash at that point. Hmmm...

Suppose I wanted to write a mission-critical application: how can
I prevent NEW() from crashing? That is, how can I determine, before
calling NEW(), whether it will succeed?

If the answer is "you can't," then how does one write a correct
Modula-3 program that uses NEW()?  (i.e. one that can be proved to
terminate with correct results)

I wonder if any of the other checked runtime errors are similarly
non-deterministic.

Daniel W. Connolly        "We believe in the interconnectedness of all things"
Software Engineer, Hal Software Systems, OLIAS project   (512) 834-9962 x5010
<connolly@hal.com>                   http://www.hal.com/%7Econnolly/index.html


-- 
Daniel W. Connolly        "We believe in the interconnectedness of all things"
Software Engineer, Hal Software Systems, OLIAS project   (512) 834-9962 x5010
<connolly@hal.com>                   http://www.hal.com/%7Econnolly/index.html


======================================================================= 13 ===
Date:    9 May 1994 18:07:10 GMT
From:    stellanl@vaxkab.e.kth.se (Stellan Lagerstroem)
Subject: Re: Problem building M3-3.1 on ALPHA_OSF 1.3B (part 2)


Ok, now I have got the compiler running, compiling small programs etc. Great.
However, programs in games/ and trestle/tutorial/ compile nicely, BUT
when run crash immediately with "segmentation fault" in malloc...

We have seen this before on programs that linked statically with X, so
I tried redoing the link step and removing the -L/usr/lib before the X librarie
s
which made it work.
Is there a good place to make m3build do the link this way?

Emptying "import_X11R4()"
in boot-ALPHA_OSF/m3build/templates/ALPHA_OSF
does not work...

Stellan

-- 
--- Stellan Lagerstrom, VMS system manager, School of E.E.
--- Royal Institute of Technology, Stockholm, Sweden


======================================================================= 14 ===
Date:    Mon, 9 May 1994 19:22:11 PDT
From:    janssen@parc.xerox.com (Bill Janssen)
Subject: Re: Non-deterministic Error Conditions?

I'd suggest that you look at src/libm3/src/runtime/common/RTMisc.m3, and
decide if what that code does with `fatal' errors (including CRE's), is
really what you need.  You might more specifically also look at
src/libm3/src/runtime/common/RTAllocator.m3.

Bill


======================================================================= 15 ===
Date:    10 May 1994 00:41:01 GMT
From:    larryr@slapshot.pa.dec.com (Larry Rau (Migration Software))
Subject: Re: Problem building M3-3.1 on ALPHA_OSF


in DEC OSF/1 v2.0 the header file signal.h now includes 
defines for sc_sp

............larry


======================================================================= 16 ===
Date:    10 May 1994 23:23:56 +1000
From:    richard@cs.anu.edu.au (Richard Walker)
Subject: Shared libs on SPARC again

Hi again.  Well, after a break of two years, I'm working
with Modula-3 again.  Would someone please let me know
what I need to do to get shared libraries working
under SunOS 4.1.3 in Modula-3 release 3.1?
(I'm presuming that it's a change to the SPARC
m3build template.)

Richard.
-- 
Richard Walker                            richard@cs.anu.edu.au
Department of Computer Science            Aust:  (06) 249 5689
The Australian National University        Intl: +61 6 249 5689
Canberra, ACT 0200, Australia             Fax:  +61 6 249 0010


======================================================================= 17 ===
Date:    10 May 94 23:17:29
From:    fn00@gte.com (Farshad Nayeri)
Subject: Re: Shared libs on SPARC again


In article <2qo1tcINNfh6@barnard.anu.edu.au> richard@cs.anu.edu.au (Richard Wal
ker) writes:

   Would someone please let me know what I need to do to get shared
   libraries working under SunOS 4.1.3 in Modula-3 release 3.1?

See "file://ftp.gte.com/pub/m3/m3-sparc.html", the SPARC release note
for Modula-3 3.1 as a good start.

Send corrections or suggestions to m3-sparc@gte.com. Thanks, --farshad

--
  ///                       |
 {@,@}                      |  
 (...)     Farshad Nayeri   |  I ran out of neat quotes.
  " "      nayeri@gte.com   |   


======================================================================= 18 ===
Date:    Wed, 11 May 1994 15:03:42 GMT
From:    kramer@inf.fu-berlin.de (Markus)
Subject: [request] writing a m3makefile-generator


I started with Modula-3 to find out if it could be an interesting language to
introduce in university.
So I wrote my first m3makefile. 

Now I wonder if someone has written a parser who is capable to get all
what is neccessary from the m3-source files.

Having to repeat to the linker what is written down
makes a bad impression. 


Markus




======================================================================= 19 ===
Date:    11 May 1994 18:52:35 GMT
From:    qs101@pelican.cl.cam.ac.uk (Quentin Stafford-Fraser)
Subject: Any useful obliq add-ons?

Obliq is great fun, and as I started writing some extensions for it, I asked
myself whether anybody else already had useful Obliq add-ons they
could make available.

I didn't get much of an answwer, so I thought I would ask you... :-)

Quentin

 ----------------------------------------------------------------------
                       Quentin Stafford-Fraser
            
 Cambridge University Computer Lab        Rank Xerox Cambridge EuroPARC
 qs101@cl.cam.ac.uk                           fraser@europarc.xerox.com
 Tel: +44 223 334411                                Tel: +44 223 341521
 Fax: +44 223 334679                                Fax: +44 223 341510

           http://pelican.cl.cam.ac.uk/people/qs101/me.html
 ----------------------------------------------------------------------
--
 ----------------------------------------------------------------------
                       Quentin Stafford-Fraser
            
 Cambridge University Computer Lab        Rank Xerox Cambridge EuroPARC


======================================================================= 20 ===
Date:    Wed, 11 May 1994 20:54:32 GMT
From:    bcrwhims@undergrad.math.uwaterloo.ca (Carsten Whimster)
Subject: Modula-3 port

Hi all,

I posted a short while ago regarding attempting an OS/2 2.x port of
SRC Modula-3, and got a number of replies. I have come to several
conclusions:
1) the hendrik... address in the porting list is not reachable from
   where I live. I presume his involvement is dead.
2) SRC is just about to come out with version 3.2 of Modula-3, so
   starting a 3.1 port now would be a waste. Therefore, I am going to
   wait for that to happen first.
3) The port is non-trivial, and is going to take a lot more time and
   effort than I had first imagined. I am going to get the Linux version
   first, and then when I am familiar with that, try the OS/2 port.
4) I can give no firm dates on this project, due to other commitments.
   If anyone is willing to help, that would be wonderful. If anyone is
   unsatisfied at the pace of the port, they are welcome to take it over.
   I don't particularly want to do the port, I just want it done :)
5) For lack of a better name to put on the list, please put mine on. I
   can't find anyone else who is willing to take it on.
6) I can't promise I'll be able to do it, but I get good marks in
   school, so I can't be completely hopeless. I will give it my best
   shot.
If anyone has any comments, helpful hints, or anything else, please
feel free to mail me. I won't be lifting a finger until 3.2, though.
-- 
-------------------------------------------------------------------
Carsten Whimster              --- EDM/2 Associate Editor
bcrwhims@uwaterloo.ca         --- EDM/2 Book Review columnist
                              --- TEAM-OS/2


======================================================================= 21 ===
Date:    12 May 1994 18:02:36 GMT
From:    siva@csgrad.cs.vt.edu (Siva Challa)
Subject: ** CFP: OOPSLA'94 Workshop on Multi-Language Object Models **

OOPSLA94 Workshop Announcement and Call for Position Papers:
---------------------------------------------------------------------

Workshop Name:  Multi-Language Object Models

Workshop Overview: 

The purpose of this workshop is to bring together experts from
industry and academia who are using object-oriented techniques to
achieve interoperability among application components that may be
implemented in different programming languages, perhaps distributed
across heterogeneous architectures. This workshop is motivated by the
need for an open, but integrated, distributed computing environment
and the desire for more effective reuse of software components
implemented in different programming languages. Some key problems are
the level of object abstraction and the granularity of run-time
integration.

Goals and Focus:  

This workshop focuses on object models that incorporate more features
than the current "least common denominator" models and remain
interoperable among different object-oriented languages.  Of interest
are both the techniques (e.g., meta-object protocols, reflection,
common run-time environment) for achieving these models as well as
specific models that embody a richer set of features (e.g., SOM,
DOM). Some of the important questions to be addressed are: How can an
extensible object model be realized? What are the performance costs of
extensibility? What degree of interoperability is sacrificied by
inconsistent extensions?  Can a single framework integrate languages
from different paradigms? Is an approach that is limited to only a few
languages too narrow for the needs of real applications? Participants
should be prepared to discuss: (1) how a diverse set of features can
be supported in the model, and (2) how the aspects of scalability,
debugging, fault-tolerance, performance, etc.  are realized.


Requirements for Attendance: 

Interested individuals are invited to submit a position paper limited
to five (5) pages indicating their experience with the workshop theme
with particular reference to above list of issues. It is particularly
encouraged that the position paper include the statement of specific
topics or questions that should be addressed at the workshop.  Each
position paper should be sent via email in Postscript form or mailed
hardcopy to the addess listed below.  Each position paper should
provide complete contact information, including email address, phone
number, and fax number for the primary author. Submission must be
received no later than August 15, 1994. Interested individuals are
encouraged to send at the earliest possible time a brief email message
to the organizers indicating their interest and giving a short
description (keywords, title) of their position paper.

Authors of selected papers may be asked to extend their papers for
inclusion in a workshop proceedings to be published in a special-issue
journal.


Organizers:    Dennis Kafura, Virginia Tech
	       Greg Lavender, MCC

Submissions:   Dr. Dennis Kafura    
               Department of Computer Science
               Virginia Tech
               Blacksburg, VA 24061-0106
               Phone: +1.703.231.5568
               Email: kafura@cs.vt.edu
               Fax:   +1.703.231.6075

A World Wide Web page for the workshop can be found at 
'http://actor.cs.vt.edu/whats-new.html'



======================================================================= 22 ===
Date:    Fri, 13 May 1994 14:21:54 GMT
From:    bcrwhims@undergrad.math.uwaterloo.ca (Carsten Whimster)
Subject: Re: Modula-3 port

In article <CpoF2x.5w7@oasis.icl.co.uk>,
Simon Johnston <skj@oasis.icl.co.uk> wrote:
>In article <Cpnoqx.M4L@undergrad.math.uwaterloo.ca> you wrote:
>: Hi all,
>
>: I posted a short while ago regarding attempting an OS/2 2.x port of
>: SRC Modula-3, and got a number of replies. I have come to several
>: conclusions:
>: 1) the hendrik... address in the porting list is not reachable from
>:    where I live. I presume his involvement is dead.
>Probably - I never heard from him.
>
>: 2) SRC is just about to come out with version 3.2 of Modula-3, so
>:    starting a 3.1 port now would be a waste. Therefore, I am going to
>:    wait for that to happen first.
>Good plan.
>
>: 3) The port is non-trivial, and is going to take a lot more time and
>:    effort than I had first imagined. I am going to get the Linux version
>:    first, and then when I am familiar with that, try the OS/2 port.
>If you need ANY OS2 help, mail me we have 100+ developers here, all OS2
>development, the source to MS OS2 1.3, and so we can always try. We are
>also a good (ready and willing) test site for anything you can offer us.

Will do.

>: 4) I can give no firm dates on this project, due to other commitments.
>:    If anyone is willing to help, that would be wonderful. If anyone is
>:    unsatisfied at the pace of the port, they are welcome to take it over.
>:    I don't particularly want to do the port, I just want it done :)
>Fine, we do however need someone to lead the project and coordinate the
>effort even if they don't do it. Looks like your hand is in the air !!

I am more than willing to coordinate the effort. I just don't know if
I have the technical know-how to do it alone.

>: 5) For lack of a better name to put on the list, please put mine on. I
>:    can't find anyone else who is willing to take it on.
>Ok.
>
>: 6) I can't promise I'll be able to do it, but I get good marks in
>:    school, so I can't be completely hopeless. I will give it my best
>:    shot.
>Thats all anyone can ask, good luck, and remember theres lots of us out
>here who want an OS2 version and have even less time. Were all looking to
>you to save our souls from C ;->

:) :) :) I regularly get into discussions with people who like the
freedom of C, and say that "if you know what you are doing, you don't
need strong typing etc". I usually respond that if you know what you
are doing, you don't need C, you can just use assembly code or machine
code :) I have been looking for an alternative language for so long I
don't care to try to remember. I had a brief fling with Ada, but
Modula-3 looks like it.

>: If anyone has any comments, helpful hints, or anything else, please
>: feel free to mail me. I won't be lifting a finger until 3.2, though.
>Good, lets me know when you start though.

Will do. I'll post to the groups, and send mail directly to all those
who have sent me notes.

>: Carsten Whimster              --- EDM/2 Associate Editor
>whats EDM/2 ?

Electronic Developer's Magazine for OS/2. You can find it at
ftp.cdrom.com in /pub/os2/2_x/program/newsltr or something like that.

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


-- 
-------------------------------------------------------------------
Carsten Whimster              --- EDM/2 Associate Editor
bcrwhims@uwaterloo.ca         --- EDM/2 Book Review columnist
                              --- TEAM-OS/2


======================================================================= 23 ===
Date:    Fri, 13 May 1994 15:20:41 GMT
From:    mmeola@cahill.ecte.uswc.uswest.com (Matt Meola)
Subject: Text.FromChars


Has anyone had any difficulties with Text.FromChars?  When I feed it a
Ctypes.char_star, I get the message, "types are not assignable".

Is there a way to convert a Ctypes.char_star into a TEXT?



-- 

(********************************************************)
(* Matt Meola, NRA Life Member, Militiaman, Libertarian *)
(* "Gun control means using two hands."                 *)
(********************************************************)


======================================================================= 24 ===
Date:    13 May 94 14:18:12
From:    fn00@gte.com (Farshad Nayeri)
Subject: Re: Text.FromChars


In article <MMEOLA.94May13092041@cahill.ecte.uswc.uswest.com> mmeola@cahill.ect
e.uswc.uswest.com (Matt Meola) writes:

   When I feed it a Ctypes.char_star, I get the message, "types are
   not assignable".

That's because Text.FromChars requires an ARRAY OF CHAR argument. You
are passing in Ctypes.char_star which (I believe) is a REF CHAR.
References to characters and arrays of characters in Modula-3 are
distinct types, unlike the way C treats them.

   Is there a way to convert a Ctypes.char_star into a TEXT?

Try M3toC.StoT or CopyStoT. The M3toC would be useful if you are
messing with C strings from Modula-3. Unless you are trying to connect
up with some C code, it is probably a good idea not to use C strings
from Modula-3.

Good luck, --farshad
--
  ///                       |
 {@,@}                      |  
 (...)     Farshad Nayeri   |  I ran out of neat quotes.
  " "      nayeri@gte.com   |   


======================================================================= 25 ===
Date:    13 May 1994 18:37:48 GMT
From:    rrw1000@cus.cam.ac.uk (Richard Watts)
Subject: Re: Text.FromChars

In article <MMEOLA.94May13092041@cahill.ecte.uswc.uswest.com>,
Matt Meola <mmeola@cahill.ecte.uswc.uswest.com> wrote:
>
>Has anyone had any difficulties with Text.FromChars?  When I feed it a
>Ctypes.char_star, I get the message, "types are not assignable".

That's because a Ctypes.char_star is not an ARRAY OF CHAR. It's an
UNTRACED REF char (char being the subrange [-16_80 .. 16_7F] on
my Linux machine).

>
>Is there a way to convert a Ctypes.char_star into a TEXT?

 Yes.

M3toC.StoT(a: char_star): TEXT - which may not copy the
                                 original string (a).

M3ToC.CopyStoT(a : char_star): TEXT - which is guaranteed
				 to copy a. 

 From a brief example (Uuio.read()ing a C string, then
converting and outputting it), M3toC.StoT works fine.

>
> [blank lines deleted]
>(********************************************************)
>(* Matt Meola, NRA Life Member, Militiaman, Libertarian *)
>(* "Gun control means using two hands."                 *)
>(********************************************************)



======================================================================= 26 ===
Date:    14 May 1994 07:47:12 GMT
From:    connolly@ulua.hal.com (Dan Connolly)
Subject: Re: Non-deterministic Error Conditions?

In article <chnizHEB0KGW83AiFA@holmes.parc.xerox.com> janssen@parc.xerox.com (B
ill Janssen) writes:

   Newsgroups: comp.lang.modula3
   From: janssen@parc.xerox.com (Bill Janssen)
   Date: Mon, 9 May 1994 19:22:11 PDT

   I'd suggest that you look at src/libm3/src/runtime/common/RTMisc.m3, and
   decide if what that code does with `fatal' errors (including CRE's), is
   really what you need.  You might more specifically also look at
   src/libm3/src/runtime/common/RTAllocator.m3.

1) I'm not familiar with these filenames... they are from some
M3 implementation distribution? I don't have M3 installed or
anything like that. I just read the book...

2) This seems to be a probem with the language definition, not the
runtime interfaces. The whole attraction to the language, to me, is
the assistance it gives in writing correct programs. But as far as I
can tell, no program that uses NEW() is guaranteed to complete.

Or perhaps it's the other way around ... perhaps the language
definition says that such programs are guaranteed to complete, but
it's impossible to correctly implement the language definition!

Anyway... I'd hate to think that a program has to "peek under the
covers" and twiddle with the runtime system... but perhaps in
pracitce it's not so bad. And perhaps evenutally the interface
to do this will become a standard interface.

Dan
-- 
Daniel W. Connolly        "We believe in the interconnectedness of all things"
Software Engineer, Hal Software Systems, OLIAS project   (512) 834-9962 x5010
<connolly@hal.com>                   http://www.hal.com/%7Econnolly/index.html


======================================================================= 27 ===
Date:    12 May 1994 20:34:13 GMT
From:    siva@vtaix.cc.vt.edu (Siva Challa)
Subject: ** CFP: OOPSLA'94 Workshop on Multi-Language Object Models **

OOPSLA'94 Workshop Announcement and Call for Position Papers:
---------------------------------------------------------------------

Workshop Name:  Multi-Language Object Models

Workshop Overview: 

The purpose of this workshop is to bring together experts from
industry and academia who are using object-oriented techniques to
achieve interoperability among application components that may be
implemented in different programming languages, perhaps distributed
across heterogeneous architectures. This workshop is motivated by the
need for an open, but integrated, distributed computing environment
and the desire for more effective reuse of software components
implemented in different programming languages. Some key problems are
the level of object abstraction and the granularity of run-time
integration.

Goals and Focus:  

This workshop focuses on object models that incorporate more features
than the current "least common denominator" models and remain
interoperable among different object-oriented languages.  Of interest
are both the techniques (e.g., meta-object protocols, reflection,
common run-time environment) for achieving these models as well as
specific models that embody a richer set of features (e.g., SOM,
DOM). Some of the important questions to be addressed are: How can an
extensible object model be realized? What are the performance costs of
extensibility? What degree of interoperability is sacrificied by
inconsistent extensions?  Can a single framework integrate languages
from different paradigms? Is an approach that is limited to only a few
languages too narrow for the needs of real applications? Participants
should be prepared to discuss: (1) how a diverse set of features can
be supported in the model, and (2) how the aspects of scalability,
debugging, fault-tolerance, performance, etc.  are realized.


Requirements for Attendance: 

Interested individuals are invited to submit a position paper limited
to five (5) pages indicating their experience with the workshop theme
with particular reference to above list of issues. It is particularly
encouraged that the position paper include the statement of specific
topics or questions that should be addressed at the workshop.  Each
position paper should be sent via email in Postscript form or mailed
hardcopy to the addess listed below.  Each position paper should
provide complete contact information, including email address, phone
number, and fax number for the primary author. Submission must be
received no later than August 15, 1994. Interested individuals are
encouraged to send at the earliest possible time a brief email message
to the organizers indicating their interest and giving a short
description (keywords, title) of their position paper.

Authors of selected papers may be asked to extend their papers for
inclusion in a workshop proceedings to be published in a special-issue
journal.


Organizers:    Dennis Kafura, Virginia Tech
	       Greg Lavender, MCC

Submissions:   Dr. Dennis Kafura    
               Department of Computer Science
               Virginia Tech
               Blacksburg, VA 24061-0106
               Phone: +1.703.231.5568
               Email: kafura@cs.vt.edu
               Fax:   +1.703.231.6075

A World Wide Web page for the workshop can be found at 
'http://actor.cs.vt.edu/whats-new.html'




======================================================================= 28 ===
Date:    Mon, 16 May 1994 22:00:00 GMT
From:    dagenais@froh.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: [request] writing a m3makefile-generator


   Now I wonder if someone has written a parser who is capable to get all
   what is neccessary from the m3-source files.

   Having to repeat to the linker what is written down
   makes a bad impression. 

There is a bit more information. You may not want to include all the files
in the directory to build the program, you can specify if the interfaces
should be exported or not (Interface vs interface...), say if you are
building a library or a program...

Mick Jordan i think had something to generate the old m3makefiles. Of
course the most difficult part is to find automatically the needed
libraries. Otherwise you could get most of the work done with:

ls *.i3 | sed -e 's/^/interface("/' -e 's/$/")/' >>m3makefile
ls *.m3 | sed -e 's/^/implementation("/' -e 's/$/")/' >>m3makefile

But i agree that an automatic tool would be cute even though in
practice very very little time is spent building m3makefiles.
--
---------------------------------------------------------------------

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

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


======================================================================= 29 ===
Date:    17 May 94 15:58:32
From:    rbnix@damabus.zer.z-netz.rechner.amiga.software (Reiner B. Nix)
Subject: no close construct in Modula-3


I'm wondering about a large lack in Modula-3.

Using several independent modules to construct a whole program you can
initialize every module in its statement sequence of the module body.
When executing a program the statement sequence of all other modules
is done before the statement sequence of the main module.

But on other side there is no general way to specify a common
termination of these modules. Termination statements of modules should
preserve the posibility to finish the work and close needed
ressources.

For example: (using SCR Modula-3, version 3.1) it is explicit
neccessary to use Wr.Flush (Stdio.stdout) to see the last line of
output of a program.

Thinking on more complicated data structures it is not very usefull to
call termination procedures from used modules because imported modules
should act stand alone.

As a result of this it should be possible to specify both: an
initialization and a termination statement sequence for modules.
May be like this:

  (* Module A *)
  BEGIN
    Init ();
  CLOSE
    Exit ();
  END A.

While statements between BEGIN and CLOSE are init statements and are
executed before the statement sequence of the main module the
statements between CLOSE and END are termination statements and are
executed after normal or abnormal execution of the main statement
sequence.

Now a module can finish its work and free all ressources independent
from every unknown importer of this module.
--

Reiner B. Nix                 rbnix@pool.informatik.rwth-aachen.de

----------------------------------------------------------------------
  Nominiert fuer den Umweltpreis:
  das Fensehen, der groesste Recyclingunternehmen der Welt


======================================================================= 30 ===
Date:    Tue, 17 May 1994 04:45:40 GMT
From:    m4359@abc.se (Morgan Lantz)
Subject: modula3 for pc

I Wounder if there are any modula3 that i can use on my pc,under windows och
dos.

All regars Morgan Lantz.



======================================================================= 31 ===
Date:    Wed, 18 May 1994 19:46:29 +0200 (MET DST)
From:    thomas.tensi@fi.sdm.de (Dr. Thomas Tensi)
Subject: Re: no close construct in Modula-3

Hallo Reiner,


you ask about the lack of termination actions in Modula-3.

> 
> 
> I'm wondering about a large lack in Modula-3.
> 
> Using several independent modules to construct a whole program you can
> initialize every module in its statement sequence of the module body.
> When executing a program the statement sequence of all other modules
> is done before the statement sequence of the main module.
> 
> But on other side there is no general way to specify a common
> termination of these modules. Termination statements of modules should
> preserve the posibility to finish the work and close needed
> ressources.
> 
> [...]
> 
>   (* Module A *)
>   BEGIN
>     Init ();
>   CLOSE
>     Exit ();
>   END A.
> 

If I remember correctly that kind of idea was initially in the first concepts
for Oberon. Wirth and Gutknecht dropped it for a simple reason: With a little
runtime system support you can do it within the language itself.

Just assume that the runtime system offers a procedure 'RegisterTermination'
with signature (READONLY proc : PROCEDURE() ). A module can register its own
termination procedure there. Hence your example looks like this:


	MODULE A;
	  IMPORT RuntimeSystem;
	  ...
	BEGIN
	  Init();
	  RuntimeSystem.RegisterTermination(Exit);
	END A.


The runtime system module maintains a stack of procedures to call and pop
whenever something goes completely wrong. No big deal.

Note that this idea does not work for initialisation: A module cannot gain
control unless some part of it is called from outside.

Hence you do not have to add anything to the language to handle completion
apart from a library module encapsulating the runtime system.

                  Thomas


-------------------------------------------------------------------------
Dr. Thomas Tensi     |s  |d &|m  |  software design & management GmbH
                     |   |   |   |  Thomas-Dehler-Str. 18
thomas.tensi@sdm.de  |   |   |   |  81737 M"unchen, Germany.


======================================================================= 32 ===
Date:    Thu, 19 May 94 11:52:30 -0700
From:    mhb@src.dec.com ("Marc H. Brown")
Subject: Two FormsVBT Q+A's


    FormsVBT Question: Setting the fount for the TextEdit 
    with a line:
	(Font (Family "lucida") (PointSize 180))
    doesn't work.  It seems to be ignored.  However:
	(Font "-*-lucida-medium-r-*-*-18-*-*-*-*-*-*")
    works fine.  This contrasts with LabelFont, which works 
    with both styles.


Answer: The problem here is probably that there is no match for Family=lucida 
and all other field equal to their defaults for Font. I don't recall 
offhand what the defaults are, but they probably are not 'medium', 
'r', '18', and a slew of asterisks. The defaults for LabelFont are 
different. If you have some good ideas about the issue of specifying 
fonts, let me know.


    FormsVBT Question: I tried to make two separate views onto the TextEdit 
    by using a Viewport: 
        (Viewport (TextEdit NoScrollbar %buffer))
    but this leaves the TextEdit inaccessible.  Putting a NoScroll 
    in the Viewport instead of a NoScrollbar in the TextEdit makes 
    things worse. Putting a Shape round the TextEdit helps a bit, 
    but it doesn't scroll properly.  Is this a bug or am I just missing 
    the point about how Viewport and TextEdit should be used together? 

Answer: There are many bugs in Viewport and in TextEdit (I fear), but I think 
you are missing the point here. A Viewport will make its child think 
it has its minimum requested shape. If the domain of the Viewport 
is smaller, then the Viewport puts scrollbars to scroll the child. 
The min shape of a TextEdit is very small. Thus, to get a Viewport 
to put on scrollbars, you should do something like 

    (Viewport (Shape (Height 2000)(Width 500) 
       (TextEdit NoScrollbar)))

If you want the Viewport's scrollbar to be tightly coupled with the 
TextEdit, you'll need to write some M3 code that will tell reset 
the Shape of the TextEdit each time it grows. 


Keep those letters and cards comin'!






======================================================================= 33 ===
Date:    20 May 94 01:13:52
From:    rundle@degas.jrc.flinders.edu.au (Richard Rundle)
Subject: Files and Pipes

I am writing a modula 3 program which needs to read information from one
named pipe and write to another named pipe. If no information is in the pipe to
read from then the program should block.

My problem is that when I try to open the pipe(s) my program hangs.

Relevant code is as follows:

IMPORT Params;              (* For getting command line arguments *)

IMPORT FileStream, Rd, Wr;  (* For operations on files *)

IMPORT Spew;                (* outputs stuff to screen *)

VAR 
  inputfile  : Rd.T;                       (* File to read from *)
  outputfile : Wr.T;                       (* File to write to  *)
  TimeLimit  : TEXT;                       (* Holds move time limit *)
  spew       : BOOLEAN := TRUE;            (* Controls logging to screen *)

PROCEDURE Initialise() =
  VAR
    input, output : TEXT;
  BEGIN
    Spew.spew("Gomoku Started.\n",spew);
    TimeLimit := Params.Get(1);

    input := Params.Get(2);
    output := Params.Get(3);

    Spew.spew("Time Limit = " & TimeLimit & "\nReading From "
      & input & " Writing To " & output & "\n",spew);
    inputfile := FileStream.OpenRead(input);
(******* program seems to hang here, ie following line is not displayed *)
    Spew.spew("Opened pipe for writing: " & output & "\n",spew);
    outputfile := FileStream.OpenWrite(output);
    Spew.spew("Opened pipe for reading: " & input & "\n",spew);
...

Any words of advice / answers would be much appreciated.

Thanks

- Richard


======================================================================= 34 ===
Date:    20 May 1994 22:13:41 GMT
From:    barton@jhm2.eche.ualberta.ca (Bob Barton)
Subject: library reference manual?


Has anyone generated a reference manual for the modula3 library interfaces?
I know that m3totex is available but if there is someplace that has produced
the reference manual in postscript format it would be useful to have access
to it. I have tried using m3totex but seem to have some incompatibilities with
the version of tex I have here.

--,,,,
 | D |  R.L. Barton                    Department of Chemical Engineering
 | A |  Tel (403) 492-5160             University of Alberta 
 | C |  Fax (403) 492-2881             Edmonton, Alberta, Canada T6G 2G6
 | S |  Internet barton@chopin.eche.ualberta.ca
--''''


======================================================================= 35 ===
Date:    21 May 1994 01:45:28 GMT
From:    janssen@holmes.PARC.Xerox.Com (Bill Janssen)
Subject: ILU 1.6.4 available

Version 1.6.4 of the Xerox PARC Inter-Language Unification (ILU)
system is now available for general use.

WHAT'S ILU?

ILU (pronounced eye'-loo) is a system that promotes software
interoperability via interfaces.  Interfaces between what?  Whatever
units of program structure are desired; we call them by the generic
term "modules".  They could be parts of one process, all written in
the same language; they could be parts written in different languages,
sharing runtime support in one memory image; they could be parts
running in different memory images on different machines (on different
sides of the planet).  A module could even be a distributed system
implemented by many programs on many machines.  Calls across ILU
interfaces involve only as much mechanism as necessary for the calling
and called modules to interact.  In particular, when the two modules
are in the same memory image and use the same data representations,
the calls are direct local procedure calls -- no stubs or other RPC
mechanisms are involved.

ILU modules are known by their interfaces.  A module interface is
specified once in ILU's object-oriented Interface Specification
Language (called, simply, ISL).  For each of the particular
programming languages supported by ILU (currently Common Lisp, ANSI C,
C++, and Modula-3; Python, Tcl, and GNU Emacs-Lisp are in the works),
a version of the interface in that particular programming language can
be generated.  The ILU kernel library provides services which may be
used by the language-specific interface to overcome intermodule
language or address space differences.

Many existing RPC systems, such as Xerox XNS Courier, ONC RPC, and OSF
DCE RPC, have strong notions of interfaces.  ILU allows binding to
such services provided by such systems if their interfaces can be
described in ISL.  ISL has been designed to facilitate such
description (currently, only for ONC RPC; Courier and DCE RPC are in
progress).  The binding to such RPC services is done in such a way as
to be indistinguishable from binding to other ILU modules.  In fact,
properly constructed ILU modules can appear as native RPC services,
and can be manipulated by non-ILU tools designed to work with those
RPC services.

Similarly, the Object Management Group's (OMG) Common Object Request
Broker Architecture (CORBA) defines modules with explicit interfaces.
ILU allows modules that can be described with a safe subset of OMG
CORBA IDL to be used as ILU modules, as well, though the ILU object
model is not quite the same as the OMG CORBA object model.  In fact,
people wishing to experiment with CORBA may find ILU a useful
experimental platform, as it does allow module specification with OMG
IDL, and does generate ANSI C support as specified in Draft 1.2 of the
OMG CORBA specification.  As the OMG specification for a C++ mapping
is agreed upon, we intend to provide that mapping for our C++ support,
as well.

Release 1.6.4 is intended as a beta release.  Major efficiency
improvements and some usability improvements are planned for the next
release.  It has been tested lightly on SunOS 4.1.3, Sun's Solaris
2.3, and SGI's IRIX 5.2.  It is designed to be highly portable, and a
port to the Macintosh has been done (but is not included in this
release).


GETTING THE RELEASE

The release is only available via FTP from the PARC ftp server.
Perhaps the simplest way is to go through our World Wide Web home
page, ftp://parcftp.parc.xerox.com/pub/ilu/ilu.html.  It has links to
everything else, and may help answer any questions you might have.

The release notes are available as an HTML document,

  ftp://parcftp.parc.xerox.com/pub/ilu/1.6.4/announce.html.

The full source code, including documentation, is available
as a 3 MB compressed tar file as

  ftp://parcftp.parc.xerox.com/pub/ilu/1.6.4/ilu-1.6.4.tar.Z

The 1.6.4 ILU manual is also available separately, either in
Postscript (231 KB) as

  ftp://parcftp.parc.xerox.com/pub/ilu/1.6.4/ilu-manual-1.6.4.ps.Z

or via World Wide Web at

  ftp://parcftp.parc.xerox.com/pub/ilu/1.6.4/manual-html/manual_toc.html.


CONTRIBUTORS

Antony Courtney, Doug Cutting, Bill Janssen, Denis Severson,
Mike Spreitzer, Mark Stefik, Farrell Wymore


COPYRIGHT RESTRICTIONS

ILU is Copyright (c) 1991, 1992, 1993, 1994 Xerox Corporation.
All Rights Reserved.  

Unlimited use, reproduction, and distribution of this software is
permitted.  Any copy of this software must include both the above
copyright notice of Xerox Corporation and this paragraph.  Any
distribution of this software must comply with all applicable United
States export control laws.  This software is made available AS IS,
and XEROX CORPORATION DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING WITHOUT LIMITATION THE IMPLIED WARRANTIES OF MERCHANTABILITY
AND FITNESS FOR A PARTICULAR PURPOSE, AND NOTWITHSTANDING ANY OTHER
PROVISION CONTAINED HEREIN, ANY LIABILITY FOR DAMAGES RESULTING FROM
THE SOFTWARE OR ITS USE IS EXPRESSLY DISCLAIMED, WHETHER ARISING IN
CONTRACT, TORT (INCLUDING NEGLIGENCE) OR STRICT LIABILITY, EVEN IF
XEROX CORPORATION IS ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
--
 Bill Janssen  <janssen@parc.xerox.com> (415) 812-4763  FAX: (415) 812-4777
 Xerox Palo Alto Research Center, 3333 Coyote Hill Rd, Palo Alto, CA  94304
 URL:  ftp://parcftp.parc.xerox.com/pub/ilu/misc/janssen.html


======================================================================= 36 ===
Date:    22 May 1994 01:39:07 GMT
From:    najork@src.dec.com (Marc Najork)
Subject: Re: library reference manual?

Bob Barton writes:

    Has anyone generated a reference manual for the modula3 library interfaces?
    I know that m3totex is available but if there is someplace that has produce
d
    the reference manual in postscript format it would be useful to have access
    to it. I have tried using m3totex but seem to have some incompatibilities w
ith
    the version of tex I have here.

SRC Research Report 113 ("Some Useful Modula-3 Interfaces") contains 
a description of the base libraries shipped with Modula-3 version 3.1. 

This report can be obtained

  - via anonymous ftp:
      gatekeeper.dec.com:pub/DEC/SRC/research-reports/SRC-113.ps.Z

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


Here is the abstract:

    December 25, 1993                        AVAILABLE ELECTRONICALLY

    "Some Useful Modula-3 Interfaces"
    Jim Horning, Bill Kalsow, Paul McJones, Greg Nelson
    103 pages

    This manual describes a collection of interfaces defining abstractions
    that SRC's programmers have found useful over a number of years of
    experience with Modula-3 and its precursors.  We hope the interfaces
    will be useful as a "starter kit" of abstractions, and as a model
    for designing and specifying abstractions in Modula-3.


======================================================================= 37 ===
Date:    23 May 94 01:20:12
From:    vixie@vix.com (Paul A Vixie)
Subject: Re: Files and Pipes

> I am writing a modula 3 program which needs to read information from one
> named pipe and write to another named pipe. If no information is in the
> pipe to read from then the program should block.
> 
> My problem is that when I try to open the pipe(s) my program hangs.

Do both pipes have other processes on them?  That is, does the one you are
going to read from have someone else writing on it at the time of your open?
Does the one you want to write on have someone else blocked on read when you
open it for writing?  Named pipes block the first opening process until a
second one gets it open.
--
Paul Vixie
Redwood City, CA
decwrl!vixie!paul
<paul@vix.com>


======================================================================= 38 ===
Date:    Mon, 23 May 1994 13:51:36 GMT
From:    mmeola@cahill.ecte.uswc.uswest.com (Matt Meola)
Subject: Is version 3.[12] out yet?


I was wondering, what's the status of version 3.1?  Last I heard, 3.1
was "stable" on Linux and DEC platforms, others were being worked on.
How's this going?  Inquiring minds want to know! :)


-- 

(********************************************************)
(* Matt Meola        mmeola@cahill.ecte.uswc.uswest.com *)
(* NRA Life Member, Militiaman, Libertarian             *)
(* Gun control means using two hands.                   *)
(********************************************************)


======================================================================= 39 ===
Date:    24 May 1994 02:19:47 -0400
From:    keogh@anshar.shadow.net (Matt Keogh)
Subject: Skinny Dip


     \[[[[[\ [[  \[[ ^[[] \[[[[[\ \[[[[[\ [[   [[      [[[[[[\ ^[[] [[[[[[\
     [[\\\\  [[\[[_   [[  [[   [[ [[   [[ [[\ \[[      [[   [[  [[  [[\\\[[
      ____[[ [[_[[\   [[  [[   [[ [[   [[  _[[[_       [[   [[  [[  [[____
     _[[[[[_ [[  _[[ ^[[] [[   [[ [[   [[   ^[]        [[[[[[_ ^[[] [[

                           ***  THIGH CREAM  ***

               The ORIGINAL thigh cream, as seen on national TV
                   This is the NEW, SUPER STRENGTH formula
                     Accept none of the immitation creams
                            YOU'RE WORTH THE BEST!!!

     Now only $29.95 per bottle which INCLUDES shipping, handling and tax
         U.S. orders only, please.  Rush check or money order to:

                              U.S. Health Inc.
                          18524 NW 67th Ave. #311
                           Miami, Florida  33015





======================================================================= 40 ===
Date:    25 May 1994 15:59:35 GMT
From:    ahrens@informatik.hu-berlin.de (Klaus Ahrens)
Subject: m3 (3.1) on SunOS 4.1.3

After building m3 (rel. 3.1) by m3boot without serious problems
on a SPARC10 with SunOS 4.1.3 I get executables m3 and m3c which
seem to loop forever doing nothing but wasting 80% cpu time !

Any ideas or suggestions ?

Please reply by email directly.

Thanks,
Klaus Ahrens

---
  ____________________________________________________________________
/|                          |                                        |
||  Dr. K. Ahrens           |  Phone  +49-030-20181 238              |
||  FB Informatik           |  Fax    +49-030-20181 234              |
||  Humboldt-Universitaet   |  email  ahrens@informatik.hu-berlin.de |
||                          +----------------------------------------+
||  P.O.Box 1297            |                                        |
||  10099 Berlin            |                                        |
||  Germany                 |                                        |
||__________________________|________________________________________|
|/__________________________/________________________________________/




======================================================================= 41 ===
Date:    Wed, 25 May 1994 19:31:43 GMT
From:    dagenais@froh.vlsi.polymtl.ca (Michel Dagenais)
Subject: Revised Modula-3 FAQ


The revised FAQ appears below. I have received quite a bit of material
lately; if something you sent me is missing or not quoted adequately,
let me know. The FAQ will be submitted to the moderated comp.answers
and news.answers newsgroups shortly. If you have a rather long entry
in the FAQ that could be trimmed down, it would be appreciated; sometimes
rewording someone else's text is difficult. Postscript and HTML (World
Wide Web) versions of the FAQ will be made available shortly as well.
--
---------------------------------------------------------------------

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

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


======================================================================= 42 ===
Date:    Wed, 25 May 1994 19:33:46 GMT
From:    dagenais@froh.vlsi.polymtl.ca (Michel Dagenais)
Subject: Modula-3 FAQ


  Modula-3 FAQ
  Michel Dagenais, dagenais@vlsi.polymtl.ca
  v2.0, 25 May 1994

  This document contains references to most of the material available on
  the Modula-3 language, compiler, tools and libraries. It should answer
  all  the  most frequently asked questions about Modula-3.  The FAQ was
  originally written by Eric  Muller.	Send  corrections,  suggestions,
  additions   to   the	current   maintainer,	Michel	Dagenais  dage-
  nais@vlsi.polymtl.ca.

  1.  What is new?


  A single source file is now used to generate the ASCII, Postscript and
  World Wide Web versions of the FAQ. The
   How to obtain pre-compiled binaries,	Modula-3 for teaching,
   Modula-3  in	industry,  Work in progress,  wish list, and the  Who's
  who sections are new.

  The language definition and documentation for most of the libraries is
  now available on the World Wide Web (thus accessible through Mosaic)


  <A HREF=http://www.research.digital.com/SRC/modula-3/html/home.html>Modula-3 
Home </A>




  2.  The language



  2.1.	What is Modula-3?


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

  The  goal  of	Modula-3 is to be as simple and safe as it can be while
  meeting the needs of modern systems programmers.  Instead of exploring
  new  features,  they	studied	the  features	of  the Modula family of
  languages that  have	proven	themselves  in	practice  and  tried  to
  simplify them into a harmonious language.  They found that most of the
  successful features were aimed at  one  of  two  main	goals:	greater
  robustness, and a simpler, more systematic type system.

  Modula-3  retains  one  of  Modula-2's  most	successful features, the
  provision for explicit interfaces between modules.   It  adds	objects
  and  classes,	exception  handling,  garbage	collection,  lightweight
  processes (or threads), and the isolation of unsafe features.



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


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






  3.  The documentation



  3.1.	Where can I get a description of Modula-3?


  The  language	definition  and  most electronically available Modula-3
  information can be accessed on:


  <A HREF=http://www.research.digital.com/SRC/modula-3/html/home.html>Modula-3 
Home </A>



  The definition of Modula-3 is contained in:


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

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


  1. Introduction

  2. Language Definition

  3. Standard Interfaces

  4. An Introduction to Programming with Threads

  5. Thread Synchronization: A Formal Specification

  6. I/O Streams: Abstract Types, Real Programs

  7. Trestle Window System Tutorial

  8. How the Language Got its Spots

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

  Sam Harbison has written a more tutorial book about Modula3:


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

  The table of contents is as follows:


  1. Introduction

  2. Declarations

  3. Statements

  4. Basic Types

  5. Structured Types

  6. Procedures

  7. Exceptions

  8. Interfaces and Modules

  9. Generics

  10.
     Dynamic Programming

  11.
     Objects

  12.
     Threads

  13.
     Low-Level Programming

  14.
     Programming Conventions

  15.
     SRC Modula-3

  16.
     Modula-3 Syntax

  17.
     Answers to Selected Exercises

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


  <A HREF=file://gatekeeper.dec.com/pub/DEC/Modula-3/errata>Errata </A>



  If you cannot find these books at your favorite  bookstore,  here  are
  bookstores connected to the net known to carry them:

  UCI carries both books:


  <A HREF=http://bookweb.cwis.uci.edu:8042/HomeTest.html>UCI Bookstore </A>



  While	Roswell  is  known  to	at  least carry the language definition
  (SPwM3):

  Roswell Electronic Computer Bookstore


  <A HREF=gopher://owl.nstn.ns.ca/11/Other%20Gophers%20in%20Nova%20Scotia/Roswe
ll%20Electronic%20Computer%20Bookstore>Roswell Bookstore </A>






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


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


  <A HREF=file://gatekeeper.dec.com/pub/DEC/Modula-3/comp.lang.modula3>Comp.lan
g.modula3 archive </A>



  There are a couple high-level overview articles available:


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

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

  A description of the Modula-3 type system is in


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

  The Modula-3 treatment of floating-point values is described in


  o  "The  Design  of  Floating-Point  Data  Types", David Goldberg, ACM
     Letters on Programming Languages and Systems (LOPLAS),  June  1992,
     Vol 1, no.2, pp 138-151

  The core library interfaces are described and indexed in


  o  "Some  Useful  Modula-3 Interfaces", Jim Horning, Bill Kalsow, Paul
     McJones, Greg Nelson,  SRC	Research  Report  113.	Available  via
     anonymous	FTP  from  gatekeeper.dec.com  in  pub/DEC/SRC/research-
     reports/SRC-113.ps.Z


     <A HREF=file://gatekeeper.dec.com/pub/DEC/SRC/research-reports/SRC-113.ps.
Z>Libm3 </A>



  o  "Pickles: a system for automatic serialization  of	typed	values",
     Andrew  Birrell,  Greg Nelson, Susan Owicki, Edward Wobber, Systems
     Research Center, Digital Equipment Corp., in preparation.

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


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

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

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



     <A HREF=file://gatekeeper.dec.com/pub/DEC/Modula-3/contrib/vbtkit.25Mar93.
ps.Z>VBTKit </A>



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


     <A HREF=file://gatekeeper.dec.com/pub/DEC/Modula-3/contrib/formsvbt.25Mar9
3.ps.Z>VBTKit library</A>



  <A HREF=file://gatekeeper.dec.com/pub/DEC/Modula-3/contrib/formsvbt.AppC.26Ma
r93.ps.Z>VBTKit applications </A>



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


     <A HREF=file://gatekeeper.dec.com/pub/DEC/SRC/research-reports/SRC-075.ps.
Z>Zeus </A>



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


     <A HREF=file://gatekeeper.dec.com/pub/DEC/SRC/research-reports/SRC-076a.ps
.Z>Color and Sound </A>



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


     <A HREF=file://gatekeeper.dec.com/pub/DEC/SRC/research-reports/SRC-098.ps.
Z>Animation Festival </A>



  Network objects are described in the following reports:


  o  "Network  Objects",  Andrew Birrell, Greg Nelson, Susan Owicki, and
     Edward  Wobber,  SRC  Research  Report  115,  February  28,   1994.
     Available	via	anonymous   FTP	from	gatekeeper.dec.com   in
     pub/DEC/SRC/research-reports/SRC-115*.ps.Z.


     <A HREF=file://gatekeeper.dec.com/pub/DEC/SRC/research-reports/SRC-115.ps.
Z>Network Objects </A>



  o  "Distributed  garbage  collection	for  Network  Objects",	Andrew
     Birrell, David Evers, Greg Nelson, Susan Owicki, and Edward Wobber,
     SRC Research Report 116, December 1993.   Available  via  anonymous
     FTP     from     gatekeeper.dec.com     in	pub/DEC/SRC/research-
     reports/SRC-116*.ps.Z.


     <A HREF=file://gatekeeper.dec.com/pub/DEC/SRC/research-reports/SRC-116.ps.
Z>Distributed GC </A>



  While the Obliq embeddable interpreter is documented in:


  o  "Obliq: A lightweight language for network objects", Luca Cardelli,
     User's  Manual,  Systems  Research Center, Digital Equipment Corp.,
     1994.  Available  via  anonymous  FTP  from  gatekeeper.dec.com  in
     pub/DEC/Modula-3/contrib/Obliq.ps.


     <A HREF=file://gatekeeper.dec.com/pub/DEC/Modula-3/contrib/Obliq.ps>Obliq 
</A>



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

  Sedgewick's classic  text  on	computer  algorithms  is  presented  in
  Modula-3 in:


  o  Alogorithms  in Modula-3 Robert Sedgewick Addison-Wesley, 1993 ISBN
     0-201-53351-0


  4.  The implementations



  4.1.	Where can I get an implementation?


  Two implementations are available, SRC Modula-3 and a PC version of it
  (m3pc).

  As  far  as  we  know,  implementations  are	not  available	for VMS,
  Macintosh.



  4.2.	What is SRC Modula-3?


  SRC Modula-3 was built by the	DEC  Systems  Research	Center	and  is
  available    via    anonymous	ftp	from	gatekeeper.dec.com   in
  pub/DEC/Modula-3. The most recent version, release  3.1,  is	a  major
  release  and	introduces  a  native compiler, Modula-3 aware debugger,
  revised libraries (libm3), Network Objects and  the  Obliq  embeddable
  language.  It	runs  fine  on	the  DS3100 architecture and with a few
  patches on the LINUX and SPARC architectures. The previous version  is
  release 2.11.


  <A HREF=file://gatekeeper.dec.com/pub/DEC/Modula-3/release-3.1>SRC-Modula-3 <
/A>



  The  compiler	implements  the  language  defined in SPwM3.  There are
  versions for the following machines:

  o  AIX386  IBM PC running AIX/PS2,

  o  AOSF    DEC Alpha AXP running OSF/1

  o  AP3000  Apollo DN4500 running Domain/OS

  o  ARM     Acorn R260 running RISC iX 1.21

  o  DS3100  DECstation 3100 and 5000 running Ultrix 4.0 and 4.2

  o  HP300   HP 9000/300 running HP-UX 8.0

  o  HPPA    HP 700/800 running HP-UX 8.0

  o  IBMR2   IBM R6000 running AIX 3.1,

  o  IBMRT   IBM RT running IBM/4.3,

  o  LINUX   Intel 386 running LINUX

  o  NEXT    NeXT running ??

  o  NT386   Intel 386 running Windows NT

  o  OKI     Okidata 7300 (i860) running UNIX SVR4.0

  o  SEQUENT Sequent computers running ??

  o  SOL2    Sparc running Solaris 2.x

  o  SPARC   SPARCstation running SunOS 4.1.x

  o  SUN3    SUN3 running SunOS

  o  SUN386  Sun 386i  running SunOS 4.0.1

  o  UMAX    Encore Multimax running UMAX 4.3 (R4.1.1)

  o  VAX     VAX running Ultrix 3.1


  The new native compiler is based on GCC and should be fairly	easy  to
  port.	Except for the very lowest levels of the thread implementation,
  the entire system is written in Modula-3.


  4.3.	What is m3pc?


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


  <A HREF=file://gatekeeper.dec.com/pub/DEC/Modula-3/contrib/m3pc>PC Modula-3 <
/A>





	  From: laszlo@post.ifi.uni-klu.ac.at (Prof.Dr.Laszlo BOESZOERMENYI)
	  Subject: M3 pn PC





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

  The first version was ported by Klaus Preschern. Carsten Weich rewrote
  the handling of long filenames for the second version.

  You may compile, link and  run  Modula-3  programs,  without	threads.
  From	the  library modules only those are tested which are used by the
  compiler.  We are using the actual version  for  our	beginners-course
  and  we are working on "student-friendly" programming environments and
  a simple windowing graphic-library.



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




  We have built a new version of Modula-3 running on  a	PC.   You  will
  need a PC:


  o  80486 or 80386 with floatingpoint-coprocessor,

  o  at least 4 but preferable 8 MByte of RAM,

  o  20 MByte discspace free at least.

  You  can run a modified Modula-3 version 2.09 without thread- support.
  Our version features:


  o  support for Unix-like long filenames

  o  automatic compilation (to substitute the lack of m3make)

  o  library to access DOS-files and directories.

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

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

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



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


  5.  Some specific questions



  5.1.	Why is "Hello World" so large?


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


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

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


  5.2.	Why objects and interfaces?


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

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

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

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

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

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


  5.3.	What is the story with Trestle and OpenWindows?


  Mark Manasse says:

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

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


  5.4.	What is new in the 3.1 release



  o  the compiler has a new internal interface between the front-end and
     the  back-end,  M3CG.   This  interface  is  supposed to be easy to
     implement.


  o  the front-end can compute	in  the	target	arithmetic  system;  in
     particular	it is possible to cross-compile to machines with larger
     integers than the host.


  o  one  back-end  has	been  implemented   on	top	of   gcc.    The
     implementation  of M3CG interface generates the tree representation
     used internally in gcc.  From the gcc point of view, this	back-end
     looks  like a new front-end.  Using this back-end, they have cross-
     compiled solitaire for mips, alpha and 386 processors; there is  no
     reason  to	believe  that	there  would  be a problem for the other
     architectures supported by gcc.


  o  gdb has been modified to understand Modula-3 debugging  information
     produced by the back-ends.	gdb can now parse Modula-3 expressions,
     print Modula-3 values and evaluate some of	the  Modula-3	built-in
     operations.   There  is  also  a  little  bit of support for multi-
     threaded programs (you can look at the stacks of other threads).


  o  there is a replacement for m3make, m3build, that does not	rely  on
     cpp/awk/sed/make  and what not, and removes some of the limitations
     of m3make.	m3makefiles are very similar.


  o  libm3 has been  significantly  changed  by	the  Interface	Police,
     mostly in the area of OS interfaces and data structures.


  o  for  the  OS  interfaces,	the  U*	interfaces are still there, but
     applications are not supposed to use those.   Instead  they  should
     use  a  new set of interfaces that are os-independent; for example,
     there is a Pathname interface that manipulates file names; there is
     a	Process  interface  that  manipulate  child  processes.   These
     interfaces enabled a prototype port  of  the  C  based  version  to
     Windows NT machines.


  o  for  the  data  structures,  generics  have been introduced and the
     various data structures are more consistent.

  o  the runtime has been improved quite a bit.


  o  new  platforms:  Alpha  running  OSF/1,  386  running  Linux.  More
     attention was paid to the porting instructions and support.




  5.5.	When is the next release of SRC Modula-3 ?


  The  next  release will be 3.2 and should be available soon. It should
  run well for at least	the  DS3100,  SPARC  and  LINUX  architectures.
  Given	the amount of changes introduced by 3.1, a high rate of release
  can be expected for a while. While SRC can test on  DS3100,  ALPHA/OSF
  and LINUX, it can only rely on what users on other platforms tell them
  to integrate all the platform specific code.

  Because of the improved portability of the 3.1 release, ports	to  non
  Unix platforms are easier. A port to Windows NT and/or Windows 3.1 may
  be available in the future.  The Windows NT port uses native	threads.
  This	should be a good model for other implementations of Thread using
  native threads.



  6.  FTP



  6.1.	How To Obtain Pre-Compiled Binaries


  The following binaries are available for FTP. If you	are  willing  to
  provide    binaries	for   other   architectures,	please	contact
  dagenais@vlsi.polymtl.ca; they may be put on his FTP server  or  links
  to  your server can be included in the FAQ. Starting with release 3.2,
  more detailed instructions will be included  for  those  who	need  to
  install  these  binaries in different locations, for instance in their
  home directory.


  o  Release 2.11 SPARC binaries. Contains everything with shared  (with
     debugging	info)  and  static  (optimized)	libraries.   It  can be
     retrieved from ftp.vlsi.polymtl.ca:lude/modula3-2.11/run.tar.Z  and
     should    be   placed   in	/usr/local/modula3-2.11/run...   Then,
     /usr/local/modula3-2.11/run/poly/sun4.1_sparc/bin must be added  to
     your path.	Compiled by Michel Dagenais.


     <A HREF=file://ftp.vlsi.polymtl.ca/lude/modula3-2.11/run.tar.Z>SPARC Modul
a3-2.11 </A>



  o  Release  3.1  SPARC  binaries.  Only contains some of the libraries
     (libm3 and the Trestle  related  libraries)  and  only  for  static
     linking.	 It	can	be	retrieved	from
     ftp.vlsi.polymtl.ca:lude/modula3-3.1/run/poly.tar.Z and  should  be
     placed	in     /usr/local/soft/modula3-3.1/run/poly...	Then,
     /usr/local/soft/modula3-3.1/run/poly/sun4.1_sparc/bin must be added
     to your path. Compiled by Michel Dagenais.


     <A HREF=file://ftp.vlsi.polymtl.ca/lude/modula3-3.1/run/poly.tar.Z>SPARC M
odula3-3.1 </A>



  o  Release  3.1  LINUX  binaries.  Only contains some of the libraries
     (libm3 and the Trestle related libraries), static and  shared.   It
     can		 be		retrieved		from
     ftp.vlsi.polymtl.ca:lude/modula3-3.1/run/linuxm3.tar.gz and  should
     be	placed	in	/usr/local/soft/modula3-3.1...	Then,
     /usr/local/soft/modula3-3.1/run/bin must be  added	to  your  path.
     Compiled by Michel Dagenais.
     <A HREF=file://ftp.vlsi.polymtl.ca/lude/modula3-3.1/run/linuxm3.tar.gz>LIN
UX Modula3-3.1 </A>




  6.2.	What if I don't have ftp access?


  Unfortunately, DEC SRC cannot deliver Modula-3 other than by anonymous
  ftp.

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



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






  7.  Contributing



  7.1.	Can I contribute Modula-3 software?


  Certainly.  Send to m3-request@src.dec.com what  you	are  willing  to
  share, be it programs, libraries or other things.  They will be put in
  the distribution.

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


  <A HREF=file://gatekeeper.dec.com/pub/DEC/Modula-3/contrib>Contrib </A>




  o  m3rpc   an rpc system from Xerox Parc

  o  M2toM3  a translator from Modula-2 to Modula-3

  o  m3pc    an implementation of Modula-3 for PCs.



  7.2.	ILU, an object-oriented multi-lingual RPC-capable module system


  The following was recently announced by Xerox PARC:

  Version  1.6.4  of  the  Xerox  PARC	Inter-Language Unification (ILU)
  system is now available for general use.
  WHAT'S ILU?

  ILU  (pronounced  eye'-loo)  is  a  system  that   promotes	software
  interoperability  via	interfaces.  Interfaces between what?	Whatever
  units of program structure are desired; we call them	by  the	generic
  term	"modules".   They  could be parts of one process, all written in
  the same language; they could be parts written in different languages,
  sharing  runtime  support  in	one  memory  image; they could be parts
  running in different memory images on different machines (on different
  sides	of  the  planet).   A module could even be a distributed system
  implemented by many programs	on  many  machines.   Calls  across  ILU
  interfaces involve only as much mechanism as necessary for the calling
  and called modules to interact.  In particular, when the  two	modules
  are  in  the	same memory image and use the same data representations,
  the calls are direct local procedure calls -- no stubs  or  other  RPC
  mechanisms are involved.

  ILU  modules	are  known  by	their interfaces.  A module interface is
  specified  once  in  ILU's  object-oriented  Interface   Specification
  Language   (called,	simply,	ISL).	For  each  of	the  particular
  programming languages supported by ILU (currently Common Lisp, ANSI C,
  C++,	and Modula-3; Python, Tcl, and GNU Emacs-Lisp are in the works),
  a version of the interface in that particular programming language can
  be  generated.   The ILU kernel library provides services which may be
  used	by  the	language-specific  interface  to  overcome  intermodule
  language or address space differences.

  Many existing RPC systems, such as Xerox XNS Courier, ONC RPC, and OSF
  DCE RPC, have strong notions of interfaces.	ILU  allows  binding  to
  such	services  provided  by	such  systems if their interfaces can be
  described  in	ISL.	ISL  has  been	designed  to   facilitate   such
  description  (currently,  only for ONC RPC; Courier and DCE RPC are in
  progress).  The binding to such RPC services is done in such a way  as
  to  be  indistinguishable from binding to other ILU modules.	In fact,
  properly constructed ILU modules can appear as  native  RPC  services,
  and  can  be	manipulated by non-ILU tools designed to work with those
  RPC services.

  Similarly, the Object Management Group's (OMG) Common	Object	Request
  Broker  Architecture (CORBA) defines modules with explicit interfaces.
  ILU allows modules that can be described with a  safe	subset	of  OMG
  CORBA	IDL  to  be used as ILU modules, as well, though the ILU object
  model is not quite the same as the OMG CORBA object model.   In  fact,
  people  wishing  to  experiment  with	CORBA	may  find  ILU	a useful
  experimental platform, as it does allow module specification with  OMG
  IDL, and does generate ANSI C support as specified in Draft 1.2 of the
  OMG CORBA specification.  As the OMG specification for a  C++	mapping
  is agreed upon, we intend to provide that mapping for our C++ support,
  as well.

  Release 1.6.4	is  intended  as  a  beta  release.   Major  efficiency
  improvements	and some usability improvements are planned for the next
  release.  It has been tested lightly on  SunOS  4.1.3,  Sun's	Solaris
  2.3,	and SGI's IRIX 5.2.  It is designed to be highly portable, and a
  port to the Macintosh has been done  (but  is	not  included	in  this
  release).


  GETTING THE RELEASE

  The  release	is  only  available  via  FTP  from the PARC ftp server.
  Perhaps the simplest way is to go through  our  World	Wide  Web  home
  page,



  <A HREF=ftp://parcftp.parc.xerox.com/pub/ilu/ilu.html>ILU </A>



  It has links to everything else, and may help answer any questions you
  might have.

  The release notes are available as an HTML document.


  <A HREF=ftp://parcftp.parc.xerox.com/pub/ilu/1.6.4/announce.html> Announce </
A>



  The full source code, including documentation, is available as a 3  MB
  compressed tar file as


  <A HREF=ftp://parcftp.parc.xerox.com/pub/ilu/1.6.4/ilu-1.6.4.tar.Z> Source </
A>



  The	1.6.4  ILU  manual  is	also  available	separately,  either  in
  Postscript (231 KB) as


  <A HREF=ftp://parcftp.parc.xerox.com/pub/ilu/1.6.4/ilu-manual-1.6.4.ps.Z> Doc
umentation </A>



  or via World Wide Web at


  <A HREF=ftp://parcftp.parc.xerox.com/pub/ilu/1.6.4/manual-html/manual_toc.htm
l> Documentation </A>




  CONTRIBUTORS

  Antony Courtney, Doug Cutting,  Bill	Janssen,  Denis	Severson,  Mike
  Spreitzer, Mark Stefik, Farrell Wymore



  8.  Modula-3 for teaching


  Modula-3  is	very  well suited for teaching: simple yet powerful, and
  safe.	It avoids the complexity of legacy languages. It can be used to
  demonstrate  modules	and  interfaces,  object  oriented  programming,
  multi-threading  (concurrency	issues),  graphical   user   interfaces
  (Trestle,  VBTKit, FormsVBT) and even distributed programming (Network
  Objects, Obliq). Since less time is spent  by	students  and	teaching
  assistants  chasing dangling pointers and corrupted data, more time is
  available for learning the important concepts.

  It is used for teaching in a number of universities. This list is  far
  from complete, send corrections and additions to
   dagenais@vlsi.polymtl.ca.

  From: Michael Coffin (mhcoffin@tolstoy.uwaterloo.ca)

  Modula-3  is being used at the University of Waterloo for both second-
  year CS courses and some third and fourth year courses.

  From: John Kominek (jmkomine@neumann.uwaterloo.ca)

  Modula-3 is  the  primary  teaching  language	for  second  year  core
  computer science courses at the University of Waterloo.

  From: Carsten Whimster (bcrwhims@undergrad.math.uwaterloo.ca)

  University of Waterloo:

  CS246	-  Third  introductory	course	in  computer science.	Software
  engineering and software systems. Medium size projects.  Uses Modula-3
  to  demonstrate  proper OO programming, as well as general programming
  practices.

  CS241 - Fourth and  final  intro  course  to	CS.  Focuses  mainly  on
  compilers  and languages. Various assignments has students create most
  of the different parts of a compiler. Also introduces Scheme (lisp).

  From: Peter.Robinson@cl.cam.ac.uk

  University of Cambridge, England.

  The Computer Science course at the University of Cambridge teaches  ML
  as an introductory language at the beginning of the freshman year, and
  then uses Modula-3 to develop imperative programming	at  the	end  of
  that	year.  Further lectures on advanced features of the language are
  given early in the second year, together  with  separate  lectures  on
  other, specialised languages.

  The  course  has been given to about 70 students each year since 1990,
  and has developed with the language.	It ties in with	other	lectures
  on data structures & algorithms, software engineering and concurrency.
  Modula-3 is used for student group projects in the second year and for
  about	a  quarter  of	individual  projects  in the final year (where,
  interestingly, students using Modula-3 tend to earn higher grades than
  those using C/C++).

  Modula-3  is	also  used in the Computer Laboratory at Cambridge for a
  number of research projects on distributed  computing,  human-computer
  interaction and electronic CAD.

  From: Matthew.Huntbach@dcs.qmw.ac.uk

  We  have  used  it  for  three  years here at Queen Mary and Westfield
  College, London. The main problem I find with the language is the slow
  compilation  speed  on  our  teaching	machines  (Macs  running A/UX),
  otherwise it's a nice language to teach with.

  From: laszlo@ifi.uni-klu.ac.at (Laszlo BOESZOERMENYI)

  University Klagenfurt

  Modula-3  is	used	at   the   following   courses:	Undergraduate:
  Softwaretechnology-1	(actually  an introduction into programming) (on
  PCs) Softwaretechnology-2 (data structures and  algorithms)  (on  PCs)
  Graduate:  Computer  Networks (on a network of DECs and SUNs) Parallel
  Programming (on an DEC-Alpha Farm)

  Modula-3  has	been  in  use	since  ca.  one	year,	with  very  good
  experiences.

  From: pk@i3.informatik.rwth-aachen.de (Peter Klein)

  Lehrstuhl   fuer   Informatik	III,  RWTH  Aachen,  Germany:	Software
  Development Projects, now held for the  second  time	using  Modula-3.
  Aim  of  these  projects is to introduce different aspects of software
  development to graduate  students.  This  includes  project  planning,
  supervision,	design,	and  cooperative  implementation  of  small but
  usable software systems.  Central ideas of software design and object-
  oriented  implementation are presented and discussed with the concepts
  of Modula-3, which is also the implementation language.

  Future  plans:  Maybe	Modula-3  will	replace   Modula-2   in   some
  undergraduate programming lectures in the future.

  From: rro@cs.colostate.edu (Rod Oldehoeft)

  In the Computer Science Department at Colorado State University, M3 is
  envisioned as a vehicle for several courses.

  M3 is introduced in the second course (data structures)  to  implement
  the  ADT  concept,  including	generics.   In	the sophomore languages
  course, it is an example of an O-O language.	In the	junior	software
  engineering  course,	additional relevant features are brought in, and
  threads are added in the junior operating systems course.

  From: viggo@nada.kth.se

  Royal Institute of Technology. Several courses at the computer science
  department use Modula-3. The courses contain programming projects, and
  many	students   choose   to	use	Trestle.   (Dr.	Viggo	Kann,
  viggo@nada.kth.se)

  From: Arnulf Mester (mester@tamfana.informatik.uni-dortmund.de)

  University  of  Dortmund, Department of Computer Science, Germany.  An
  undergraduate course (scheduled for  September)  for	students  within
  their	second	year  of  studies  this  time	takes  Modula-3 as third
  language. Maybe  later  network  programming	courses	will  also  use
  M3/NO/Obliq.	The  Modula-3 class has it's own WWW home page which is
  planned to be filled during the class in Oktober/September this  year.


  <A HREF=http://ls4-www.informatik.uni-dortmund.de/RVS/V-PKM3/intro.html>Modul
a-3 Class </A>



  From: "Dave Snelling" (snelling@cs.man.ac.uk)

  Department  of  Computer Science, University of Manchester, Manchester
  U.K.	We have a small, interdisciplinary collection  of  people  using
  Modula-3  for	a variety of activities. Our major production code is a
  hardware architecture simulator (about 120 modules). Smaller	projects
  include a Lattice Gass model and a Shallow Water model.

  At: University of Massachusetts at Amherst

  Modula-3  is used as an input language for the Computer Science course
  on Compilation techniques. The professor is Eliot Moss.

  From: Michel Dagenais (dagenais@vlsi.polymtl.ca)

  Modula-3 is  used  as	the  main  example  in	a  graduate  course  on
  "Algorithmic	Aspects	of  CAD",  which includes a large portion on OO
  programming and databases.


  9.  Modula-3 In Industry


  A number of programming teams in industry selected Modula-3 for  their
  project.  It	encourages  good  programming  practices  and comes with
  excellent libraries for distributed  programming  and	graphical  user
  interfaces.


  From:	gwyant@cloyd.East.Sun.COM  (Geoffrey  Wyant  - Sun Microsystems
  Labs BOS)

  Sun Microsystems Laboratories, Inc. (East) is using Modula-3	(Network
  Objects,  FormsVBT)  as  the	basis  for  its	research in large scale
  distributed object systems.

  From: Farshad Nayeri (nayeri@gte.com)

  Distributed Object Computing, GTE  Labs,  Waltham,  Massachusetts  USA
  Modula-3  (FormsVBT,	Sx,  Netobj  libraries)	is  used  to  prototype
  distributed object management.  (Farshad Nayeri nayeri@gte.com).


  <A HREF=file://ftp.gte.com/pub/dom/reports/NAYE93c.ps>Report </A>



  From: Mike Elliott (elliottm@csulb.edu)

  I'm currently using M3 at Interstate Electronics  Corporation	602  E.
  Vermont Ave. Anaheim, CA 92803 USA.

  The  project	is  a  trajectory  simulator;  that is, given an initial
  position,  velocity,	and  attitude,	determine  data	concerning   a
  simulated  aircraft  at  pre-determined points in time.  The simulated
  aircraft is given a list of maneuvers to perform at specified times in
  the flight.

  The  overall	objective is to be able to test flight software involved
  in inertial and satellite navigation, by providing any desired  flight
  path,	and  to  be  able  to	easily	modify	the  simulated	inertial
  navigation instruments and satellite	readings  (i.e.,  for  different
  atmospheric models and different inertial gyro characteristics).

  Modula-3  was	chosen	as  a	fall back position.  My first choice was
  Smalltalk, since it has a good reputation for	modeling  applications,
  but  that was seen as too exotic, or too expensive, or something.  The
  eventual implementation is to be done in Ada, and the managers  wished
  the  project to be done completely in Ada, without determining whether
  a suitable Ada compiler was at hand.	Since one was not, and the  GNAT
  compiler  is	much  less mature than the SRC Modula-3 compiler, and M3
  does look vaguely like Ada, I was allowed to use M3.



  10.  Work In Progress


  The purpose of this section is to let	everyone  know	what  is  being
  worked  on.  This  is	not  a commitment to a quick release or even to
  completion.  However it may enable  parties  interested  in  the  same
  topics  to  pool  their efforts, avoid duplication or better integrate
  their packages.

  To find more information about the names mentioned, see the Who's  Who
  section.





  10.1.	The SRC Compiler


  The  compiler already implements the full language and runs on several
  platforms. Speed enhancements and support for	some  popular	non-Unix
  platforms may be expected.



  10.2.	Modula-2 To Modula-3 Converter


  A  better Modula-2 to Modula-3 converter (99% conversion...) is in the
  works under the supervision of Peter Klein.



  10.3.	On-Line Documentation


  Most library modules already contain their documentation, which may be
  extracted with m3totex. Bill Kalsow has been working on organizing and
  indexing the documentation for browsing through the World Wide Web.



  10.4.	Integrated Development Environment


  A number of groups have made experiments in this area. Tools	such  as
  VBTkit  for  the  user  interface,  m3tk  for	syntax	and  dependency
  analysis,  dynamic  linking...  could	be  used  to  produce	such  an
  environment.	It  is worth noting that precompiled interfaces are much
  easier to achieve in M3 than in several other popular languages.

  Peter Klein is working  on  a	Modula-3  development	environment  and
  associated user interface.

  Klaus	Preschern, Carsten Weich, Laszlo Boszormenyi have made the port
  of Modula-3 to the  PC.   The	M3-PC	environment  will  be  enhanced,
  especially  with  threads  and  graphics, including a student-friendly
  environment.

  David N. Gray of Lucid Inc. has been experimenting with connecting the
  Modula-3   compiler	with   the  Lucid  Energize  Programming  System
  (currently sold as a development environment for  C  and  C++	on  Sun
  SPARCstations).   He	expects to be able to make the modified compiler
  available as an unsupported as-is hack  in  a	couple	of  months,  to
  accompany the new Energize release that it works with.

  Geoff	Wyant	is  experimenting with FormsVBT/VBTKit to build a simple
  friendly development environment.



  10.5.	Useful Data Structures


  Michel Dagenais has insertable sequences. This is  like  the	existing
  Sequences  in	libm3 except that the complexity is O(log n) instead of
  O(1) but elements can be inserted anywhere, not only at  the	top  and
  bottom  of  the  sequences.  This  is	useful to keep childs in a tree
  automatically numbered or to	efficiently  keep  words  or  paragraphs
  numbered  while insertions are being made. This will be made available
  eventually but could be packaged in a relatively short time  if  there
  is a need.
  10.6.	Windowing And User Interfaces



  10.6.1.  Rotated Text


  Currently,  there  is no VBT to show non horizontal text, because of X
  windows limitations. This would be desirable and can be implemented in
  one  of  the	following  ways:  a)  open  a  pipe  to	the ghostscript
  Postscript interpreter and use  it  as  a  font  renderer,  cache  and
  display  the character bitmaps produced; b) have Bezier curves for the
  most popular Postscript fonts, Trestle handles Bezier curves;	c)  use
  the  new  text facilities in X11R6 that remove previous limitations. A
  prototype implementation of a) has  been  implemented	by  Alain  Dube
  (contact  Michel Dagenais); the performance with the cache is good but
  this remains a relatively complex solution. The b) solution  would  be
  relatively  easy  to implement but the resulting quality may not be as
  good as a real font renderer.	The c) solution may  not  be  available
  for  some  time since many workstation vendors take a long time before
  integrating the new X windows facilities.



  10.6.2.  Postscript VBTs


  It is often useful to display Postscript files in a VBT,  for	example
  for an included diagram in a document editor.

  This	can  be achieved by using the ghostscript Postscript interpreter
  as a rasterizer.  A  prototype  has  been  programmed	by  Alain  Dube
  (contact  Michel  Dagenais)  but  the performance is not too good when
  large color bitmaps are handled. An alternative implementation  is  to
  convert  Postscript  files into display lists (Bezier curves and text)
  as a preprocessing step.  Further displaying and even editing	becomes
  very	simple.	A  prototype  implementation  of  this has been done by
  Benoit Poirier (contact Michel Dagenais).



  10.7.	Persistent Objects


  With	Pickles	to  store  objects  in	files,	the  implementation  of
  persistent  objects  is simplified. Furthermore, with the m3tk library
  it is not too difficult to read a type description and  to  write  the
  needed  methods  to  handle that type. Combined with FormsVBT, network
  objects and Obliq, all the  ingredients  are	there  to  have	a  nice
  environment  for  developing	graphical  distributed applications with
  persistent state and querying facilities.

  Peter Klein has a specialized database  for  annotated  graphs,  GRAS,
  that is being re-implemented in Modula-3.

  Eliot	Moss  is  working  on	persistent  Modula-3  objects.	The main
  features are persistence through reachability, load on  demand  and  a
  very	low  overhead for using persistent objects. The high performance
  is obtained by  modifying  the  compiler  and	run-time.  Initially  a
  modified  version  of	GCC, GNU M3, was being worked on. However, with
  the release of the SRC native compiler, the  modifications  are  being
  moved to the SRC compiler instead.


  <A HREF=ftp://ftp.cs.umass.edu/pub/osl/papers> Persistency </A>

  10.8.	Abstract Syntax Tree Tools (M3 Parser)


  The  m3tk library can be used to analyze Modula-3 source code in order
  to find specific constructions (use of OBSOLETE facilities, un-handled
  exceptions),	build  source  code  browser  and  analysis tools, stubs
  generators for  network  or  persistent  objects...	Mick  Jordan  is
  preparing  the 3.2 release of m3tk and finishing the documentation, in
  his spare time.

  From: hudson@yough.ucs.umass.edu (Rick Hudson)

  If anyone is interested we have developed a Bison grammar that  parses
  the Modula-3 language input. If interested please feel free to contact
  me hudson@cs.umass.edu.



  10.9.	Computer Assisted Learning Tools (Algorithm Animation)


  The  Zeus  Algorithm	Animation package may be used to quickly develop
  graphical and animated teaching aids. Most of the algorithms described
  in  Robert  Sedgewick's  Algorithms book have been animated at DEC SRC
  through the work of Marc H. Brown.

  Animation of compilation techniques have been produced by students  at
  University of Illinois with the help of Marc Najork.

  Animation  of Memory Hierarchy (Disk, RAM, Cache) has been produced by
  Michel Dagenais and should be released soon,	after  some  tuning  and
  packaging.

  From: "Arnulf Mester" (mester@ls4.informatik.uni-dortmund.de)

  As  part  of a studental project advised by a college of mine and me a
  Mentor-like collection of Zeus-based animations of typical distributed
  algorithms   and   communication  protocols  (termed	ZADA)  has  been
  compiled.  Hopefully I'll get to include more information  and  access
  during the next weeks into our ZADA WWW home page


  <A HREF=http://ls4-www.informatik.uni-dortmund.de/RVS/zada.html>ZADA </A>





  10.10.  Presentations, Tutorials And Teaching Material


  Modula  3  is	used  for  teaching  in  a number of Universities. Some
  Modula-3 related teaching material may be  shared  between  interested
  parties.

  Michel  Dagenais has a French presentation about the Modula 3 language
  that could be distributed. An English presentation about the	Modula-3
  environment and libraries should be available later this summer.

  Geoff	Wyant	is  preparing  a  tutorial  on Modula-3 for the upcoming
  OOPSLA conference.





  10.11.  Reports And Books


  Sam Harbison is preparing a revised version of his  existing	book  on
  Modula-3. He may include more material on the new libraries.

  Laszlo Boszormenyi, Roland Mittermeir and Carsten Weich are working on
  a book (it will be published in German and in English) with the  work-
  title:

  "Programming	in  Style  -  An  Introduction	into  Programming  with
  Modula-3"

  The book will be published at Springer (in German in October 1994,  in
  English  maybe or December, or January 1995).	For the book, the M3-PC
  environment will be enhanced, especially with	threads  and  graphics,
  including a student-friendly environment.

  A  book  about writing distributed object oriented applications, using
  Modula-3,  m3build,  m3gdb,  analyze_coverage,  FormsVBT,  Obliq   and
  Network  Objects  is	being planned by Geoff Wyant, Farshad Nayeri and
  Michel Dagenais.



  10.12.  Matrix Algebra


  From:	Mike  Elliott	(elliottm@csulb.edu)	Interstate   Electronics
  Corporation

  My  project  involves	a lot of matrix algebra -- I'm loaded down with
  vectors and direction cosine matrices and stuff -- and I really wish I
  had  a  good	matrix algebra library to use.	I'm developing routines,
  but I'm currently unconvinced that my design	and  implementation  are
  optimal.


  10.13.  Floating Point Geometry Library


  Currently, an Integer geometry package is available in libm3. Portions
  of an equivalent floating point  counterpart	is  available  in  other
  applications	such  as Zeus/Mentor. Michel Dagenais has packaged these
  and completed some. It has been contributed to  m3-request@src.dec.com
  but may be distributed to those that simply cannot wait.



  10.14.  Parallel Programming


  Ernst A. Heinz writes the following:

  I would like to inform you about our ongoing Modula-3* project here at
  the University of Karlsruhe.	At the moment, we are actively	involved
  in  adding  sophisticated  dependence	and data flow analysis to DEC's
  Modula-3 compiler (release 3.x!). The Modula-3* compiler will be  able
  to   generate	code  for  real  parallel  machines,  for  networks  of
  workstations, and for standard sequential  execution.	(Our	new  IPD
  Modula-2*  system  available	by  anonymous ftp from ftp.ira.uka.de in
  "pub/programming/modula2star" may give you an	initial  feeling  about
  it!)

  Beside  my  JSPP'93  paper I have already written an extended abstract
  about a unifying semantics specification for sequential  and	parallel
  exception  handling  in  Modula-3*.  This  will  soon be extended to a
  complete unifying semantics specification for Modula-3* as a whole!

  For all interested  folks  I	have  made  my	JSPP'93	paper	publicly
  available by anonymous ftp. The title of the paper reads as follows:

  "Modula-3*:  An  Efficiently	Compilable  Extension  of  Modula-3  for
  Problem-Oriented Explicitly Parallel Programming".

  To retrieve DVI, PostScript, or compressed Postscript versions of  the
  paper please connect to i41s10.ira.uka.de by anonymous ftp. There, the
  directory pub/m3s contains the corresponding files  named  jspp93.dvi,
  jspp93.ps, and jspp93.ps.Z.


  <A HREF=file://i41s10.ira.uka.de/pub/m3s/jspp93.ps>Paper </A>






       -rw-r-----   1 ftp      ftp	 41604 Jul 14 11:33 jspp93.dvi
       -rw-r-----   1 ftp      ftp	147100 Jul 14 11:33 jspp93.ps
       -rw-r-----   1 ftp      ftp	 59443 Jul 14 11:34 jspp93.ps.Z




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

  For your information I see the abstract of my JSPP'93 paper below.


  10.14.1.   PROBLEM-ORIENTED EXPLICITLY PARALLEL PROGRAMMING MODULA-3*:
  AN EFFICIENTLY COMPILABLE EXTENSION OF MODULA-3 FOR


  Ernst	A.  Heinz,  University  of  Karlsruhe,  F.R.	Germany	(email:
  heinze@ira.uka.de)

  In this paper	we  present  the  programming	language  Modula-3*  and
  machine-independent  optimization  techniques	for its compilation. We
  consider Modula-3* to	be  a	promising  new	framework  for	problem-
  oriented explicitly parallel programming that aims at high performance
  on a variety of architectures	and  machines.	By  proposing	a  large
  collection of effective optimizations we illustrate the feasibility of
  efficient Modula-3* compilation. We ensure portability of the compiler
  by  formulating most optimizations as source-to-source transformations
  in the intermediate high-level language Modula-3pi,  an  extension  of
  Modula-3* especially designed for this task.



  11.  Wish List


  The  Modula-3	development  environment now contains a large number of
  very good tools and libraries that work nicely together.  The	purpose
  of this section is to help contributors determine what additions would
  be helpful to others.	It may get you	in  contact  with  people  that
  would	like  to  use your contribution or with people that may provide
  some items on your wanted list or team with you for their development.

  11.1.	M3Build


  The  descriptions  of programs and libraries stored in m3makefiles are
  simple and efficient. It would be interesting to be  able  to	specify
  different   m3-options   for	some	files	(debugging,  performance
  analysis...), and to have the dependency analysis  take  into	account
  previously  used options when determining modules to recompile (Michel
  Dagenais).

  Although makefiles cannot  perform  the  same	consistency  checks  as
  m3build and are more cumbersome to use, it may be useful to be able to
  drive the compiler through makefiles for training purposes (i.e. learn
  Modula-3	and	Makefiles	at	the	same	time)
  (bwbecker@watdragon.uwaterloo.ca).



  11.2.	Coverage And Performance Analysis


  Tools	already  exist	for   coverage	analysis,   pretty   printing,
  performance  analysis,  viewing  the threads and the garbage collected
  heap. It would be nice to have  these	easily	accessible  through  an
  integrated development environment (Michel Dagenais).



  11.3.	More VBTs


  An editor widget with multiple fonts (fixed and proportional character
  spacing) perhaps even	with  direct  support	for  HTML  (item  lists,
  centered headings...)	(Geoff Wyant).

  A  split  VBT	that  positions  NxM childs in aligned rows and columns
  (Geoff Wyant).

  A Graph VBT that displays arbitrary graphs (such as call trees,  cross
  references...).  This	could	be implemented adding a placement module
  (to determine the vertex positions) to work on the  existing	GraphVBT
  module (Geoff Wyant).

  Some	of  the	VBTs  implemented  in	miscellaneous libraries (such as
  GraphVBT in Mentor/Zeus) could be placed in a	more  visible	location
  such as VBTKit (Michel Dagenais).



  11.4.	Distributed Computing (Network Objects)


  Network  objects are an exciting recent addition. The underlying model
  is very simple and effective. Authentication and access  control  will
  be required in many applications.

  A  network object daemon that starts specific programs upon need, like
  inetd does using inetd.conf for most network services, would	be  very
  useful (Michel Dagenais).



  11.5.	Interfaces To Other Libraries And Programs (Tcl, Dps...)



  C functions are easily called from Modula 3.	Thus,  stubs  have  been
  produced  to	access John Ousterhout's Tcl and also Display Postscript
  from Modula 3.

  An automatic tool to produce such stubs from .h C files would be  very
  useful (Geoff Wyant). A similar tool available for ADA may be modified
  for that purpose (Michel Dagenais).

  Stubs to access the Motif X Windows library  would  be  useful  (Geoff
  Wyant).

  Similar  stubs would be desirable to access databases such as Postgres
  or Exodus and access/provide World  Wide  Web	information  using  the
  hypertext transfer protocol libraries (HTTP) (Geoff Wyant).



  12.  Who's Who


  Modula-3  enthusiasts,  users	or  contributors.  Please notify me for
  additions, corrections or removals.


  o  Robert   Ayers,   Adobe,	(ayers@Mv.Us.Adobe.Com),   the	Display
     Postscript to Modula-3 interface

  o  Andrew Birrell, DEC SRC, Network objects.

  o  Laszlo    Boeszoermenyi,	Universitaet	Klagenfurt,	Austria,
     (laszlo@ifi.uni-klu.ac.at), PC port (m3pc),  Programming  in  style
     book.

  o  Marc H. Brown, DEC SRC, VBTKit, FormsVBT, Zeus.

  o  Luca Cardelli, DEC SRC, Modula-3 definition, Obliq.

  o  Michel	Dagenais,     Ecole	Polytechnique	de    Montreal,
     (dagenais@vlsi.polymtl.ca), LINUX and SPARC M3 binaries, M3 FAQ.

  o  John D. DeTreville, DEC SRC, Incremental garbage collector.

  o  David N. Gray, Lucid Inc., Menlo Park, (gray@Lucid.Com),  interface
     between the Lucid environment and the M3 compiler.

  o  Sam Harbison, Tartan, harbison@tartan.com, Modula-3 book.

  o  Ernst   A.	Heinz,   University	of   Karlsruhe,	F.R.	Germany
     (heinze@ira.uka.de)

  o  Jim Horning, DEC SRC, Useful Modula-3 interfaces.

  o  Rick   Hudson,   University   of	Massachusetts	at	Amherst,
     (hudson@cs.umass.edu), GNU Modula-3.

  o  Mick  Jordan, Sunlabs near Palo Alto, Modula-3 definition, M3TK and
     related tools.

  o  Bill Kalsow, DEC SRC, Modula-3 definition,	M3  compiler  and  run-
     time.

  o  Peter Klein, Lehrstuhl fuer Informatik III, (pk@i3.informatik.rwth-
     aachen.de).  Modula-2 to Modula-3 converter.

  o  Mark S. Manasse, DEC SRC, Trestle.

  o  Paul McJones, DEC SRC, Useful Modula-3 interfaces.

  o  James R. Meehan, DEC SRC, VBTKit, FormsVBT.

  o  Roland    Mittermeir,     Universitaet	Klagenfurt,	Austria,
     (mittermeir@ifi.uni-klu.ac.at), Programming in style book.

  o  Eliot    Moss,    University    Of	Massachusetts   At	Amherst,
     (moss@Cs.Umass.Edu), GNU Modula-3.

  o  Eric Muller, DEC SRC, M3 compiler and run-time.

  o  Marc Najork, DEC SRC, 3D animation.

  o  Greg Nelson, DEC SRC, Modula-3 definition, Systems Programming with
     Modula-3 book editor, Trestle, Network objects.

  o  Farshad  Nayeri,  GTE Near Boston, (fn00@Gte.Com), m3-sparc mailing
     list.

  o  Frode Odegard, (frode@Odegard.Com), commercial Modula-3 support.

  o  Susan Owicki, DEC SRC, Network objects.

  o  Klaus     Preschern,     Universitaet     Klagenfurt,	Austria,
     (preschern@ifi.uni-klu.ac.at), PC port (m3pc).

  o  Robert  Sedgewick,	Princeton  University,	Algorithms  in Modula-3
     book.

  o  Jorge Stolfi, Brazil, Computational geometry procedures.

  o  Carsten Weich, Universitaet  Klagenfurt,  Austria,	(weich@ifi.uni-
     klu.ac.at), PC port (m3pc), Programming in style book.

  o  Edward Wobber, DEC SRC, Network objects.

  o  Geoff  Wyant,  Sunlabs  Near  Boston,  (gwyant@East.Sun.COM), SPARC
     port.



























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

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

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


======================================================================= 43 ===
Date:    Fri, 27 May 1994 09:57:56 -0700 (PDT)
From:    David L Miller <dlm@cac.washington.edu>
Subject: Re: Macros in Modula-3


You could use the C-style macros and run your code through the C
pre-processor before compiling, but that is very ugly... 

|\ |  |\/|  David L. Miller    dlm@cac.washington.edu  (206) 685-6240
|/ |_ |  |  Software Engineer, Pine Development Team   (206) 685-4045 (FAX)
University of Washington, Networks & Distributed Computing, JE-20
4545 15th Ave NE, Seattle WA 98105, USA

On Fri, 27 May 1994, Salman Ahmed wrote:

> Is there any way to define Macros in Modula-3 the way C allows (sth like this
 : #define SUM(X+Y) (X+Y), where this definition can be arbitrarily complex).
> 
> Please reply by email to SSAHMED@NAPIER.UWATERLOO.CA
> 
> Thanks in advance.
> 
> 
> -- 
> 
> _Salman Ahmed_
> 
> 
> -----------------------------------------------------------------------------
-
> 
> "Remember when you were young, you shone like the sun, 
> Shine on you Crazy Diamond .....
> 
> Come on you raver, you seer of visions, come on you painter, you piper, 
> you prisoner, and shine!" 
> 			  - Pink Floyd
> 
> 


======================================================================= 44 ===
Date:    Fri, 27 May 1994 13:46:44 GMT
From:    ssahmed@napier.uwaterloo.ca (Salman Ahmed)
Subject: Macros in Modula-3 

Is there any way to define Macros in Modula-3 the way C allows (sth like this :
 #define SUM(X+Y) (X+Y), where this definition can be arbitrarily complex).

Please reply by email to SSAHMED@NAPIER.UWATERLOO.CA

Thanks in advance.


-- 

_Salman Ahmed_


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

"Remember when you were young, you shone like the sun, 
Shine on you Crazy Diamond .....

Come on you raver, you seer of visions, come on you painter, you piper, 
you prisoner, and shine!" 
			  - Pink Floyd


======================================================================= 45 ===
Date:    27 May 1994 18:47:23 GMT
From:    najork@src.dec.com (Marc Najork)
Subject: Re: Macros in Modula-3

One use of macros is to inline non-recursive function definitions. 
The m3 <* INLINE *> pragma is intended to provide a safer way to do this. 
Here is what SPwM3 has to say about INLINE:

    We recommend supporting the two pragmas <* INLINE *> and <* EXTERNAL *>. 
    The pragma <* INLINE *> precedes a procedure declaration to indicate 
    that the procedure should be expanded at the point of call.

And here is what Harbison has to say:

    The pragma <* INLINE *> can precede a procedure declaration to 
    indicate that calls to the procedure should be expanded in-line, 
    eliminating the overhead of an actual call. Inlined procedures 
    can be local to a module or can be exported from an interface 
    (in which case the INLINE pragma should appear in the interface).

    Some Modula-3 implementations may ignore the INLINE pragma completely. 
    Others may be unable to in-line procedures imported from interfaces, 
    because that is difficult to implement. Methods probably cannot 
    be inlined, since inlining is not compatible with dynamic binding.

Unfortunately, as far as SRC m3 goes, INLINE hasn't been implemented (yet).

-- Marc


======================================================================= 46 ===
Date:    28 May 1994 10:15:11 GMT
From:    laszlo@post.ifi.uni-klu.ac.at (Laszlo BOESZOERMENYI)
Subject: Re: Macros in Modula-3

Karl-Heinz Eder is working (with a group of students) 
on a macro-preprocessor for M3.
His mail-adress is
charly@ifi.uni-klu.ac.at


*********************************
* Prof. Laszlo Boeszoermenyi	*
* Institut fuer Informatik	*
*                              	*
* Universitaet Klagenfurt	*
* Universitaetsstr. 65-67  	*
* A-9022 Klagenfurt / Austria	*
*                              	*
* e-mail:			*
* laszlo@ifi.uni-klu.ac.at	*
* Tel.: 			*	
* 00-43-463-2700-509 		*
* 00-43-463-2700-506 (secr.)	*
* Fax.:		 		*
* 00-43-463-2700-505 		*
*********************************


======================================================================= 47 ===
Date:    Mon, 30 May 1994 06:06:33 GMT
From:    brister@netcom.com (james brister)
Subject: BSDI port?

Has anyone ported M3 to BSDI (1.1)? I'll probably attempt to port the LINUX
version myself if no-one else has done it.

Thanks

James
-- 
James Brister                                                  brister@vix.com
                                       	                  decwrl!vixie!brister


======================================================================= 48 ===
Date:    30 May 1994 02:54:04 GMT
From:    hendrik@CAM.ORG (Hendrik Boom)
Subject: Re: Macros in Modula-3

David L Miller (dlm@cac.washington.edu) wrote:

: You could use the C-style macros and run your code through the C
: pre-processor before compiling, but that is very ugly... 

If you're going to use an off-the-shelf macro processor, you are probably
better off with ML/1, a portable macro processor written in the 60's
by P.J. Brown, and distributed through DECUS.  I'm not sure
what the appropriate source for ML/1 is now, but I hear runours that
someone in England, possibly at the University of Canterbury in Kent,
maintains it and does ports.

If anyone has better information, please let me know.

I have a not-up-to-date copy, but it would take quite some effort to 
dearchive it, and I have mislaid the documentation.

ML/1 macros are specified using a sequence of delimiters, not just a name.
I have used them to add statements like the following to Algol W:
	for i in list x do uuu
where i, x, and uuu are macro parameters, and 'uuu' evennests properly,
allowing begin-end blocks or just a statement ending in a semicolon.

I have always thought is a shame that the C macro processor ignores all that
was known about macro processing at the time, but has become the de-facto
canonical macro processor today, even though it is woefully inadequate even
for C.

: |\ |  |\/|  David L. Miller    dlm@cac.washington.edu  (206) 685-6240
: |/ |_ |  |  Software Engineer, Pine Development Team   (206) 685-4045 (FAX)
: University of Washington, Networks & Distributed Computing, JE-20
: 4545 15th Ave NE, Seattle WA 98105, USA

: On Fri, 27 May 1994, Salman Ahmed wrote:

: > Is there any way to define Macros in Modula-3 the way C allows (sth like th
is : #define SUM(X+Y) (X+Y), where this definition can be arbitrarily complex).
: > 
: > Please reply by email to SSAHMED@NAPIER.UWATERLOO.CA
: > 
: > Thanks in advance.
: > 
: > 
: > -- 
: > 
: > _Salman Ahmed_
: > 
: > 
: > ---------------------------------------------------------------------------
---
: > 
: > "Remember when you were young, you shone like the sun, 
: > Shine on you Crazy Diamond .....
: > 
: > Come on you raver, you seer of visions, come on you painter, you piper, 
: > you prisoner, and shine!" 
: > 			  - Pink Floyd
: > 
: > 


======================================================================= 49 ===
Date:    Mon, 30 May 1994 01:06:01
From:    j_mcarthur@BIX.com (Jeffrey McArthur)
Subject: Re: Macros in Modula-3

A slightly more radical approach would be convert one of the
Literate programming tools to Modula-3.  Since Modula-3 is
based on Modula-2 it would not be much work to convert Mangle
and Meave to process Modula-3 instead of Modula-2 syntax.

This would give the added bonus of full literate programming
techniques.

----
    Jeffrey M\kern-.05em\raise.5ex\hbox{\b c}\kern-.05emArthur
    a.k.a. Jeffrey McArthur          ATLIS Publishing
    phone: (301) 210-6655            12001 Indian Creek Court
    fax:   (301) 210-4999            Beltsville, MD  20705
    home:  (410) 290-6935            email: j_mcarthur@bix.com

The opinions express are mine and mine alone.  They do not reflect
the opinions of ATLIS Publishing or any part of ATLIS Systems.
ATLIS does NOT pay for my access to the Internet.


======================================================================= 50 ===
Date:    30 May 1994 12:55:40 GMT
From:    stolfi@cmos.dcc.unicamp.br (Jorge Stolfi)
Subject: Re: Fixed Point vs. Floating Point


To: dewar@cs.nyu.edu (Robert Dewar)
In-reply-to: dewar@cs.nyu.edu's message of 30 May 1994 02:29:57 -0400
Mime-Version: 1.0
Content-Type: text/plain, charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: Fixed Point vs. Floating Point
Reply-to: stolfi@dcc.unicamp.br

--text follows this line--

    > If it is really true that Modula 3 requires all intermediate
    > results to be in the "correct" floating-point type, then the
    > code must be truly horrible on a Pentium. That's the trouble,
    > this most obvious semantics isn't viable as the only possible
    > semantics on machines like the Pentium which do all arithmetic
    > in extended mode.

Well,

The philosophy (if not the letter) of the Modula-3 spec requires that
the same expression evaluates to the same value on any IEEE-conforming
machine.  (This, if you recall, was also the primary motivation behind
the IEEE standard.)

Since the extended mode is not part of the IEEE standard, and may not
be available on all machines, it follows that any arithmetic
expression involving double-precision quantities must be evaluated
using double-precision operations and temporaries.

If you DO want Modula-3 to evaluate an expression with
extended-precision, just convert the operands to EXTENDED, or declare
them that way.

--stolfi

PS. Pardon my ignorance, but I thought that the IEEE standard required
that the result of A := B * C be correctly rounded in all cases.  Does
that work correctly on the Pentium?  (i.e. will the Pentium round B*C
to the nearest extended, and then round the result to the nearest
double? Is that equivalent to rounding B*C to the nearest double?)

--------------------------------------------------------------------
Jorge Stolfi                                | Tel: +55 (192) 39-8442
Computer Science Dept. (DCC-IMECC)          |      +55 (192) 39-3115
Universidade Estadual de Campinas (UNICAMP) |  
Internet: stolfi@dcc.unicamp.br             | Fax: +55 (192) 39-7470
--------------------------------------------------------------------


======================================================================= 51 ===
Date:    30 May 1994 17:48:56 GMT
From:    krste@ICSI.Berkeley.EDU (Krste Asanovic)
Subject: Re: Fixed Point vs. Floating Point

In article <STOLFI.94May30095540@cmos.dcc.unicamp.br>, stolfi@cmos.dcc.unicamp.
br (Jorge Stolfi) writes:
|> 
|> Since the extended mode is not part of the IEEE standard, and may not
|> be available on all machines, it follows that any arithmetic
|> expression involving double-precision quantities must be evaluated
|> using double-precision operations and temporaries.

I thought double-precision was not a required part of the standard
either :-)

(see Sec 3.4)

-- 
Krste Asanovic
International Computer Science Institute      Email: krste@icsi.berkeley.edu
1947 Center Street,                           Phone: +1 (510) 642-4274 x143
Berkeley, CA 94704, USA                         Fax: +1 (510) 643-7684


======================================================================= 52 ===
Date:    Mon, 30 May 94 22:53:54 GMT
From:    Scott Martin <smartin@ozemail.com.au>
Subject: Re: Macros in Modula-3

>  Is there any way to define Macros in Modula-3 the way C allows 
(sth 
like this : #define SUM(X+Y) (X+Y), where this definition can 
be 
arbitrarily complex).
> 
> Please reply by email to SSAHMED@NAPIER.UWATERLOO.CA
> 
> Thanks in advance.
> 
> 
> -- 
> 
> _Salman Ahmed_
> 

Oh please no, let's not stuff M3 up with dangerous shortcuts!

Scott






======================================================================= 53 ===
Date:    31 May 1994 15:36:36 +0800
From:    lingo@perth.DIALix.oz.au (Bill Rayer)
Subject: Re: Fixed Point vs. Floating Point

Hello everyone

I've been following this thread with interest for a week or so.

What is anyone's view on the "currency" format used in Microsoft
Quick basic? This stores an integer in 8 bytes with implicit decimal
scaling of 10,000. Thus it represents fractional values exactly
(to 4 decimal places)

Bill Rayer

lingo@dialix.oz.au



======================================================================= 54 ===
Date:    31 May 1994 06:25:12 GMT
From:    stolfi@cmos.dcc.unicamp.br (Jorge Stolfi)
Subject: Re: Fixed Point vs. Floating Point


    > [Me:] Pardon my ignorance, but I thought that the IEEE standard
    > required that the result of A := B * C be correctly rounded in
    > all cases.  Does that work correctly on the Pentium?

Well, I have just been told (by e-mail) that the Pentium will indeed
round B*C to the nearest extended; and then, if requested, round the
result to the nearest single or double.  Which is not in general
equivalent to directly rounding B*C to the nearest single double.

If this is true, does it mean that the Pentium does NOT conform
to the IEEE FP standard?

Will my next PC come with a sticker saying 

  "Intel inside, IEEE out there somewhere"? 
  
8-)

Is this the beginning of the end of the IEEE standard?

--stolfi

--------------------------------------------------------------------
Jorge Stolfi                                | Tel: +55 (192) 39-8442
Computer Science Dept. (DCC-IMECC)          |      +55 (192) 39-3115
Universidade Estadual de Campinas (UNICAMP) |  
Internet: stolfi@dcc.unicamp.br             | Fax: +55 (192) 39-7470
--------------------------------------------------------------------


======================================================================= 55 ===
Date:    Tue, 31 May 1994 14:12:46 GMT
From:    dagenais@froh.vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: Macros in Modula-3


   A slightly more radical approach would be convert one of the
   Literate programming tools to Modula-3.  Since Modula-3 is
   based on Modula-2 it would not be much work to convert Mangle
   and Meave to process Modula-3 instead of Modula-2 syntax.

   This would give the added bonus of full literate programming
   techniques.

You already get a form of literate programming with m3totex. As a matter
of fact, several libraries (libm3, Trestle, VBTKit, FormsVBT...) are
already documented in this way. This may not be a direct consequence,
but the M3 libraries are much better documented than most publically
available libraries on the net.
--
---------------------------------------------------------------------

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

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


======================================================================= 56 ===
Date:    Tue, 31 May 94 15:36:46 EDT
From:    BERGINF@PACEVM.DAC.PACE.EDU (Joseph Bergin)
Subject: m3build problem

Help. I just built m3.3.1. When trying to use m3build I get an error on
reading the first line of the first interface file in my src directory to
the effect that a) RT0.i3 can't be found and b) RT0.i3 isn't an interface.
Well, RT0.i3 is in my usr/local/m3/include as I expect, but it seems m3build
expects otherwise. What did I do wrong? Oh yes, after issuing m3boot and
m3ship on my DecStation, I did delete the build directory boot-RS3100. Thanks.


======================================================================= 57 ===
Date:    1 Jun 1994 01:02:54 GMT
From:    stolfi@cmos.dcc.unicamp.br (Jorge Stolfi)
Subject: Re: Fixed Point vs. Floating Point


    > [Me:] I have been told that the Pentium will round B*C to the
    > nearest extended; and then, if requested, round the result to
    > the nearest single or double.  Which is not in general
    > equivalent to directly rounding B*C to the nearest single
    > double.

Oops! It seems I have, hum, extrapolated a bit from what people
told me.

Douglas Priest and Norbert Juffa kindly explained to me that, by
setting two "precision" bits in the Pentium's FP control register, one
*can* get "A op B" correctly rounded to single or double, in just one
step.

So the Pentium IS IEEE compliant --- almost.

Why "almost"? Well, there are two little snags.

(1) Setting the control bits correctly may be quite a hassle.  At the
    very least, they have to be set between any two consecutive
    operations with different precisions; and perhaps at other times
    too, e.g. on procedure boundaries.

    I don't know how easy that operation is on the Pentium.  I would
    guess it requires

      1. storing the FP control register into memory;
      2. loading that word into an ordinary register;
      3. masking off the two precision bits;
      4. setting them to the desired value;
      5. storing the modified word into memory;
      6. loading that word into the FP control register;
      7. performing the operation.

    Yuck.

(2) It seems that, in register-to-register operations, the control
    bits only determine the precision of the *mantissa*, but not the
    range of the exponent.  So, single- or double-precision
    intermediate results which would be denormalized or infinite in a
    strict IEEE machine may retain full precision when computed on the
    Pentium; and this extra precision may affect the final result.

    Some of these effects may be avoidable by forcing a store+load of
    every intermediate result to memory, thus forcing low-exponent
    values to be denormalized.  However, besides being expensive, this
    solution will cause those denormals to be rounded twice, which is
    incorrect.

Thus, as my informant put it, "the goal of getting the same result
on any IEEE machine is not likely to be achieved."

Would some Pentium expert please check these comments?

--stolfi

--------------------------------------------------------------------
Jorge Stolfi                                | Tel: +55 (192) 39-8442
Computer Science Dept. (DCC-IMECC)          |      +55 (192) 39-3115
Universidade Estadual de Campinas (UNICAMP) |  
Internet: stolfi@dcc.unicamp.br             | Fax: +55 (192) 39-7470
--------------------------------------------------------------------


======================================================================= 58 ===
Date:    31 May 94 22:54:41
From:    fn00@gte.com (Farshad Nayeri)
Subject: Re: m3build problem

In article <9405311943.AA06958@inet-gw-1.pa.dec.com> BERGINF@PACEVM.DAC.PACE.ED
U (Joseph Bergin) writes:

   Help. I just built m3.3.1. When trying to use m3build I get an
   error on reading the first line of the first interface file in my
   src directory to the effect that a) RT0.i3 can't be found and b)
   RT0.i3 isn't an interface.  Well, RT0.i3 is in my
   usr/local/m3/include as I expect, but it seems m3build expects
   otherwise. What did I do wrong? Oh yes, after issuing m3boot and
   m3ship on my DecStation, I did delete the build directory
   boot-RS3100. Thanks.

Starting with version 3.?, SRC Modula-3 requires that you include a
line "import (libm3)" in your m3makefile; this statement was left out
of the example "m3makefile" in the 3.1 documentation.

To fix, just add "import (libm3)" in your favorite m3makefile.

I believe the documentation error has been fixed for release 3.2, so
this may not be an FAQ for much longer.

--farshad
--
  ///                       |
 {@,@}                      |  
 (...)     Farshad Nayeri   |     ...neat quote coming soon...
  " "      nayeri@gte.com   |  


