======================================================================== 1 ===
Date:    Mon, 2 Mar 92 10:58:08 PST
From:    <swart@src.dec.com>
Subject: Re: errors and exceptions


There is a reasonable way of implementing a slight restriction of path
2, errors as control transfers.  That is to note at compile time whether
a runtime exception generated by an expression can be caught or not.
If the runtime error exception cannot be caught then the compiler is
free to optimize as much as it wants.  If it can be caught it must
be careful.  A runtime error can be caught if the expression occurs
statically inside of a TRY EXCEPT for the indicated exception or the
procedure the expression is contained in mentions the exception.  In
this way the compiler can note whether the kind of optimizations that
you envision can be made.

For example in,

    PROCEDURE X() = 
    BEGIN
      TRY
        INC(x); INC(y);
      EXCEPT
      | RTException.IntegerOverflow:
      END;
    END X;

The increments of x and y cannot be done in parallel.  While in

    PROCEDURE X() = 
    BEGIN
      INC(x); INC(y);
    END X;

they can.

The slight restriction of path 2 have to do with catching an exception
resulting from an unhandled exception.  For example in:

    MODULE Main;
    VAR x: INTEGER := LAST(INTEGER);
    VAR y: INTEGER := 0;
    PROCEDURE X() = 
    BEGIN
      INC(x); INC(y);
    END X;
    
    BEGIN
      TRY
        X();
      EXCEPT
      ELSE
        <* ASSERT y = 0 *>
      END;
    END Main.

One would like not to have to make this program work.

Garret


======================================================================== 2 ===
Date:    2 Mar 92 11:56:13 GMT
From:    os102@cl.cam.ac.uk (Oliver Stephens)
Subject: Trestle Question

How does a filter change the domain of it's child without calling the
child's Reshape method ?

This may sound like an odd question, but I have implemented a
StretchyBorderVBT which is like a BorderedVBT except that it always
gives it's child it's preferred size (useful when the child has size
constraints such as a constant aspect ratio or can only use a discrete
number of different sizes).  In the filter's Reshape method, I want to
change the domain of the child to be the maximum possible, then call
GetShapes which returns the child's preferred shape within this domain,
then resize the filter borders and call the child's Reshape method with
it's final position.  If I use the child's Reshape method for the initial
change, then the child will attempt a redraw twice - once in the wrong
position, then again in the correct position.

At the moment, I have it working by changing the child's domain field
explicitly (filter.ch.domain) but I don't think I'm supposed to do this.

I would be very grateful for any `guru' comments/suggestions,

Olly

-------------------------------------------------------------------------
Olly Stephens                                oliver.stephens@cl.cam.ac.uk
Computer Laboratory
University of Cambridge    Loved you there and then, and now like a sheep
United Kingdom                                             - Van Morrison


======================================================================== 3 ===
Date:    2 Mar 92 17:00:57 GMT
From:    Olin.Shivers@cs.cmu.edu
Subject: errors and exceptions

Requiring run-time errors to raise exceptions can impede optimising
compilers. For example, suppose we define integer arithmetic overflow
to raise an exception, which if not caught, terminates the program.
Sounds reasonable.

However, you've just about eliminated any possibility of the compiler
reordering integer ops -- like hoisting very-busy exps, or rescheduling
them inside basic blocks to fill load or jump delay slots. Doing the operation
early might prevent some side-effect visible to the exception handler
code from happening. Defining the error to terminate your program makes it
easier to justify doing this.

Another example: I loop from 0 to K over an array. A fancy compiler
hoists the bounds check outside the loop. If array bounds errors are
*errors* - not allowed in correct programs, and terminate the program,
then it's OK that the program terminated early, without first executing
the initial loop iterations where the index was legal.

Now suppose instead we require index errors to generate an exception.
The user might have been counting on that exception happening -- maybe
he was trying to loop over all the legal indices of the array in a kind
of sleazy way. There are people who really do this in ML.

The problem with exceptions is that they introduce these extra control edges
into your program. It's just about impossible to remove them because 
the control transfers have dynamic scope, being set up by exception handlers,
so how can you prove no one is going to handle them? Furthermore, they
encourage a business-as-usual exploitation of run-time errors which makes
it hard to define your language to allow for early detection of
these errors. The errors have to happen right when they happen, so forget
about hoisting stuff out of loops. For operations like integer arithmetic
and array indexing, that's not so good.

So, there are two possible paths you can take about run-time errors:
1. Fail-stop: A run-time error is not exhibited by a correct program.
   A program will always detect and report these errors. Early detection
   is allowed, that is error detection is not ordered wrt the external
   side-effects of the partially-executed errorful program.

2. Errors-are-just-another-control-transfer: Errors are always detected,
   causing exceptions to be raised. The errorful operation and the exception
   it triggers is ordered wrt the side-effects of the program (after all,
   it's just a conditional branch).

You need to be careful which errors are put in which set.
My belief is that array bounds checks definitely belong in set 1,
for reasons of efficiency and programming style. Arithmetic ops?
Maybe you could provide two different arithmetic modules. 

Excuse me if this isn't germane to M3. I don't have my M3 book on me
in HK, so I'm a little fuzzy on details of the language.
	-Olin


======================================================================== 4 ===
Date:    Mon, 2 Mar 92 12:09:33 PST
From:    <swart@src.dec.com>
Subject: Re: errors and exceptions


Note that the reason Ada has to resort to pragmas and compiler modes
to solve this problem is because the language does not have RAISES
clauses.  If Ada had RAISES clauses it could fix things in the simple
and elegant (if I say so myself) way I suggested.

Note that a pragma or compiler switch that allows the compiler to
generate code that violates the language semantics is an "illegal"
pragma (a.k.a.  "a hack").  Changing the language to allow "imprecise"
exceptions and adding pragmas to tighten things up is less of a hack
but it certainly muddies up the language semantics.

Garret


======================================================================== 5 ===
Date:    Mon, 2 Mar 1992 20:13:35 GMT
From:    mday@pion.lcs.mit.edu (Mark Day)
Subject: Re: errors and exceptions

   Olin.Shivers@cs.cmu.edu writes:

   So, there are two possible paths you can take about run-time errors:
   1. Fail-stop: A run-time error is not exhibited by a correct program.
      A program will always detect and report these errors. Early detection
      is allowed, that is error detection is not ordered wrt the external
      side-effects of the partially-executed errorful program.

   2. Errors-are-just-another-control-transfer: Errors are always detected,
      causing exceptions to be raised. The errorful operation and the exception
      it triggers is ordered wrt the side-effects of the program (after all,
      it's just a conditional branch).

   You need to be careful which errors are put in which set.
   My belief is that array bounds checks definitely belong in set 1,
   for reasons of efficiency and programming style. 

I might believe the efficiency concern.  My experience with CLU causes
me to disbelieve the programming style concern.  

Certain kinds of programs have markedly improved clarity if you can
write them as "do this to the array element, but if it isn't there
then do this other thing."  

If I wrote a lot of scientific programs that did regular marching
through arrays in tight loops, I might prefer efficiency to expressive
power; but for a lot of the code that I write, it would be a pain in
the neck to have an out-of-bounds access be fatal.

--Mark Day

mday@lcs.mit.edu





======================================================================== 6 ===
Date:    Mon, 2 Mar 92 11:47:52 PST
From:    msm@src.dec.com (Mark S. Manasse)
Subject: Re: Trestle Question


The shape methods in Trestle aren't designed to do what you want; they
are designed to give us a way to compute the overall layout constraints
for top-level windows.  If you want use the domain of your window to
compute your desired shape, you'll get double repaints.  You could avoid
the double repaint in several ways: by defining a PaintBatch procedure that
trapped painting, by examining the domain of your parent VBT, or by
defining a private protocol for the purposes of your computation.

The last would probably be my choice; if you place an entry on the child's
PropSet containing the bounding rectangle that you would like it to work within
,
the child shape method could read that and do whatever it wanted.  But that's
still unlikely to get the child to ask for a sensible shape in the first place.

As an alternative, the child could simply center itself in whatever domain it
receives, and then call NewShape.  When the parent reshapes the child, it could
provide the old domain; the child could notice that the only part it cared
about was in fact preserved.

An alternative would be for the VBT to handle reshapes by simply marking the
VBT, and, if necessary, calling NewShape (but only if the VBT wasn't already
marked, to avoid infinite looping).  On a call to the redisplay method, call
the reshape method of the child.  This loses you the ability to use your old
old domain, unless you guess what part of it might be useful, and copy it.

Mark



======================================================================== 7 ===
Date:    2 Mar 92 19:27:01 GMT
From:    emery@Dr_No.mitre.org (David Emery)
Subject: Re: errors and exceptions

There is a great amount of "knowledge" on this topic in Ada.
Generally, it's known in the Ada community as "11.6", after the part
of the Ada Reference Manual which discusses the interactions between
exceptions and optimizations.  

There is always a tension between precision and optimization.  The
current Ada 9X approach is to permit more optimizations in general,
but to have a compiler mode (as one of the specified annexes, which
may not be supported by all compilers) that requires 'canonical'
execution.  

In some respects, this is equivalent to a pragma that permits or
forbids the compiler to do substantial reordering, etc, during
optimization. 

				dave


======================================================================== 8 ===
Date:    Tue, 3 Mar 1992 10:55:16 GMT
From:    aet@ee.mu.OZ.AU (bert thompson)
Subject: oberon for sun4 sparc

can someone please tell me where i'd find an oberon implementation for
a sun4 sparc. i don't want to have to install it at /usr/local/contrib/...
but instead in my own home directory.
(i ftp'ed an oberon compiler but couldn't get it going because it wanted
to live at /usr/local/contrib/...)
(as a last resort i may try to convince the sysadmin to install it.)

even an interpreter would be very nice. i just want to check out the
language for myself: it's seems to be just what i've always wanted
in a procedural language!

	most grateful for any help!

	bert (an ordinary non-superuser 8^)

(btw, sorry for posting in these groups but there is no comp.lang.oberon.)


======================================================================== 9 ===
Date:    3 Mar 92 16:26:25 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: Modula-3 Video

I recently received a brochure from University Video Communications
listing a series of videotapes by noted authorities on various CS
topics.  One of them was Jim Donahue talking on Modula-3. Since
Jim's affiliation was listed as Olivetti Research, I guess this video
is at least a couple of years old. I have not seen it, nor do I know
anything about the company.

According to the brochure, the videos are normally $60 each, but
there's a special offer of 4 for $100. Contact University Video
Communications, P.O.Box 5129, Stanford, CA 94309. Phone (415)
327-0131; fax (415) 813-0315.

Sam Harbison 
Pine Creek Software; Suite 300; 305 South Craig Street; Pittsburgh, PA 15213;
USA. Phone&FAX: +1 412 681 9811. E-mail: harbison@bert.pinecreek.com.


======================================================================== 10 ===
Date:    Tue, 3 Mar 1992 10:53:33 -0500 (EST)
From:    Dick Orgass <do12+@andrew.cmu.edu>
Subject: SRC Modula-3 Runtime Question

I've been working on making the Andrew Toolkit available as a set of
shared Modula-3 libraries.  This is being done by retaining the C code
that provides the function and adding Modula-3 interfaces and replacing
the ATK runtime with the Modula-3 runtime.  The result has been a
significant simplification of the runtime code.

There is one piece of the ATK runtime that I don't quite know how to
replace/improve.  At runtime, I would like to be able to bind the
invocation of specific methods of specific objects to key sequences, eg,
^S to the search-forward method of the text object.

Finding the actual method pointer is clean and easy.  However, I don't
know how to find the signature of the method proc at runtime so that I
can LOOPHOLE the ADDRESS in the MethodSuite to a procedure with the
correct signature.  Using an explicit type makes the whole thing much
more reliable.

I would appreciate hints, references to papers, etc.

Many thanks!

Dick


======================================================================== 11 ===
Date:    Tue, 3 Mar 1992 17:19:55 GMT
From:    rau_larry@tandem.com
Subject: Case of keywords

Here is an EASY question??!!  

In the first report on Modula-3 it stated that Keywords (I can't remember 
if Reserved words are included) could  be either ALL uppercase or ALL
lower case.

In the revised Modula-3 report and in the "Green" book nothing is
said about this, nor is their a mention that this has indeed changed.

So, my question is am I to  assume that Keywords must be ALL 
UPPERCASE??

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




======================================================================== 12 ===
Date:    4 Mar 92 06:46:06 GMT
From:    sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: Modula-3 Video

In article <1992Mar3.162625.1679@bert.pinecreek.com> harbison@bert.pinecreek.co
m (Sam Harbison) writes:
>I recently received a brochure from University Video Communications
>listing a series of videotapes by noted authorities on various CS
>topics.  One of them was Jim Donahue talking on Modula-3. Since
>Jim's affiliation was listed as Olivetti Research, I guess this video
>is at least a couple of years old. I have not seen it, nor do I know
>anything about the company.
>
>According to the brochure, the videos are normally $60 each, but
>there's a special offer of 4 for $100. Contact University Video
>Communications, P.O.Box 5129, Stanford, CA 94309. Phone (415)
>327-0131; fax (415) 813-0315.
>
>Sam Harbison 
>Pine Creek Software; Suite 300; 305 South Craig Street; Pittsburgh, PA 15213;
>USA. Phone&FAX: +1 412 681 9811. E-mail: harbison@bert.pinecreek.com.


======================================================================== 13 ===
Date:    4 Mar 92 07:32:54 GMT
From:    sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: Modula-3 Video

Oops, pressed the wrong key so a junk posting was sent.  Sorry.

In article <1992Mar4.064606.6841@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writ
es:
>In article <1992Mar3.162625.1679@bert.pinecreek.com> harbison@bert.pinecreek.c
om (Sam Harbison) writes:
>>I recently received a brochure from University Video Communications
>>listing a series of videotapes by noted authorities on various CS
>>topics.  One of them was Jim Donahue talking on Modula-3. Since
>>Jim's affiliation was listed as Olivetti Research, I guess this video
>>is at least a couple of years old. I have not seen it, nor do I know
>>anything about the company.

Our department has bought several of those tapes.
I have seen Donahue's video once, and I quite liked it.
The lecture and short discussion has been recorded in late November 1989,
thus very shortly before Olivetti Research was closed, but Donahue's
speech gave me the impression that he did not know yet what was coming.
I think that this later history was mentioned in the titles.

The picture quality of these UVC videotapes is not overwhelming
but sufficient (texts on the slides or screen displays are large enough).
It's near to what I get when recording TV programmes at half speed.
Conversion from NTSC to PAL may have been a factor, so perhaps they are
a bit better in America.  Unfortunately, some speakers of the series
(not Donahue) mumble rather unclearly, thus some presentations may be
difficult for foreign students to understand.

----------------------------------------------------------------------
Markku Sakkinen (sakkinen@jytko.jyu.fi)
       SAKKINEN@FINJYU.bitnet (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------


======================================================================== 14 ===
Date:    4 Mar 92 16:43:43 GMT
From:    geb@amber.Rational.COM (Gary Barnes)
Subject: Is there a definitive "definition of Modula-3"?


Does the language have a generally agreed upon definition yet?  I have
the original "Modula-3 Report" out of Olivetti and I have a copy of
Samuel Harbison's new "Modula-3" book, but...

These two references describe related but distinctly different
languages and they both contain noticable holes, ambiguities, and
contraditions about the edges and hard semantic rules of the language.
Does Modula-3 have a hard edged standard yet?  Is there a group
working on making a standard for it (ala IEEE, ANSI, ISO groups) or
working on writing a single definitive definition such as Ada's LRM?
Or is the language largely defined by what the SRC compiler accepts or
rejects?

On a related question, has anyone started on an equivalent to Ada's
ACVC tests for testing out an implementation to see whether it
implements "Modula-3" or merely "something that looks a lot like
Modula-3"?

Gary E. Barnes		geb@Rational.com



======================================================================== 15 ===
Date:    4 Mar 92 14:19:49 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: SRC Modula-3 Runtime Question

Why don't you LOOPHOLE it to a procedure type with first parameter REFANY and
second parameter the key sequence that was used to invoke it? The methods
actually used would of course have only self and a key sequence as arguments.
Note that the REFANY technique would allow people to bind arbitrary
procedures, too, that were not included as methods by the definer of the
object. Or maybe I'm misunderstanding the whole nature of what you were
asking. Note that you need to know what instance to invoke this on, too.
Again, using REFANY in your key tables is general. Making this all truly type
safe is another matter. I can imagine doing that only by having a KeySequence
method in a high level interface and having all the objects inherit from that
and having each object dispatch the different key sequences internally (the
last part is the unpleasant part). Seems we really would like to have
closures, which you can approximate with a record but will have potential type
safety problems.
--

		J. Eliot B. Moss, Assistant Professor
		Department of Computer Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu


======================================================================== 16 ===
Date:    4 Mar 92 14:11:42 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: Case of keywords

Yes, if I remember correctly, that was changed between the original report and
the revised report. Personally, I liked the old way fine, not being a fan of
all upper case for just about anything, but that's what happened ... Eliot
--

		J. Eliot B. Moss, Assistant Professor
		Department of Computer Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu


======================================================================== 17 ===
Date:    4 Mar 92 14:12:26 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: Modula-3 Video

I have seen the video and it is a pretty good introduction to the history,
motivation, and major features of M3 ....			Eliot
--

		J. Eliot B. Moss, Assistant Professor
		Department of Computer Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu


======================================================================== 18 ===
Date:    Wed, 4 Mar 92 15:02:07 PST
From:    muller@src.dec.com (Eric Muller)
Subject: Re: Is there a definitive "definition of Modula-3"?

In article <4872@igor.Rational.COM>, geb@amber.Rational.COM (Gary Barnes) write
s:

> Does the language have a generally agreed upon definition yet?  I have
> the original "Modula-3 Report" out of Olivetti and I have a copy of
> Samuel Harbison's new "Modula-3" book, but...

@book		(m3-Nel91,
title		= "System Programming with Modula-3",
editor		= "Greg Nelson",
publisher	= "Prentice Hall",
isbn		= "0-13-590464-1",
year		= 1991,
what		= "The bible for Modula-3.  Includes the language
                   reference manual and papers on the I/O library,
                   threads, and the Trestle window system."
)

-- 
Eric.



======================================================================== 19 ===
Date:    4 Mar 92 18:58:41 GMT
From:    chased@rbbb.Eng.Sun.COM (David Chase)
Subject: Re: Is there a definitive "definition of Modula-3"?

In article <4872@igor.Rational.COM> geb@amber.Rational.COM (Gary Barnes) writes
:
>
>Does the language have a generally agreed upon definition yet?

Yes -- Harbison's book may be correct already, but I believe that
Nelson's is supposed to be The Truth.

>These two references describe related but distinctly different
>languages and they both contain noticable holes, ambiguities, and
>contraditions about the edges and hard semantic rules of the
>language.

There were 3 published versions of the language -- two described in
(both) DEC-SRC and Olivetti tech reports, and the third described in
Nelson's book.

> ... Is there a group
>working on making a standard for it (ala IEEE, ANSI, ISO groups) or
>working on writing a single definitive definition such as Ada's LRM?

I hope like hell not.  I've got more faith in the people on the
original committee (in spite of my disagreements from time to time)
than I do in any standards committee, especially in this new world of
standards-as-marketing-weapons.  There was enough feedback from the
peanut gallery (implementors and porters) to keep them from screwing
up too badly.  The book defines a useable language.

>Or is the language largely defined by what the SRC compiler accepts or
>rejects?

No, this is definitely not the case.

David Chase
Sun


======================================================================== 20 ===
Date:    5 Mar 92 14:00:21 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: Re: Is there a definitive "definition of Modula-3"?

In article <4872@igor.Rational.COM> geb@amber.Rational.COM (Gary Barnes) writes
:
>Does the language have a generally agreed upon definition yet? ...

Both Greg's and my book *should* describe the same language.  If mine
disagrees with Greg's then there's a bug and I'd like to know about
it. Ditto about "noticable holes, ambiguities, and contraditions about
the edges and hard semantic rules of the language."

>...Has anyone started on an equivalent to Ada's ACVC tests for testing ...

I think this would be a good idea, but it hasn't seemed to have gotten
to the top of anyone's stack. Perhaps Rational should abandon that
silly Ada stuff and switch to Modula-3?

Sam Harbison 
Pine Creek Software; Suite 300; 305 South Craig Street; Pittsburgh, PA 15213;
USA. Phone&FAX: +1 412 681 9811. E-mail: harbison@bert.pinecreek.com.


======================================================================== 21 ===
Date:    6 Mar 1992 23:10:12 -0600
From:    wilson@cs.utexas.edu (Paul Wilson)
Subject: Re: Safe cheap objects for Modula 3

In article <MOSS.92Feb27093847@ibis.cs.umass.edu> moss@cs.umass.edu writes:
>>>>>> On 26 Feb 92 19:20:51 GMT, Hans_Boehm.PARC@xerox.com said:
>
>Hans> Let's keep things in perspective.  There is a significant cost to
>Hans> allocating collectible storage rather than stack allocating storage.
>Hans> [...]  You may need some locking or synchronization on allocation, or
>Hans> risk fragmenting the heap by dividing it up on a per thread basis.
>
>What I had in mind for gm3 was a generational heap where each thread has its
>own nursery but the older spaces are shared. One then needs synchronization
>only on scavenging and promotion, which require coordination anyway. I'd be
>interested in folks thoughts on this approach (not on generational vs. other
>schemes, but this multi-thread generational scheme).

It seems to me that it will be a good idea to have separate nurseries
for each threads if and only if they're running on separate processors.

If you have high rates of heap allocation, the reuse of the nursery
(creation area) will dominate your cache-level locality.  (I don't know
how high is high, to any precision, or how many M3 programs get there.)

Basically, each nursery will have a big nasty footprint in the cache.
If multiple threads share the same nursery, you'll have several big
nasty footprints---any multitasking you do at a timescale relevant
to the cache will cause your working set to be the set union of
the nursery sizes, if heap allocation rates are high. 

Unfortunately, it may be more efficient to use separate nurseries,
unless you can gc opportunistically.  If multiple processes allocate
from the same hunk of memory, they'll use it up and cause a gc
sooner, even though none of them will have made lots of progress,
so they'll still have a lot of live intermediate results.  Having
them share a nursery could make each of them less efficient, unless
it's too big to fit in cache anyway.

One way around this would be to task switch preferentially after
a gc scavenge.  When you've emptied the nursery, you task switch
and let the next process use it.  That's better than task switching
halfway through, and having one process cause another process's
data to be copied.  If this scheduling doesn't conflict with other
things, then you get the best of both worlds.

On the other hand, in the ideal case you have one processor per process,
and can have each nursery entirely cached in one processor's cache.


>I'd like to explore the optimization of stack allocation of some objects, and
>in fact have a pending grant proposal on gc that would include that as part of
>a comprehensive gc system. I agree that stack allocation is cheaper than heap
>allocation, but I want to get some numbers that show the difference. Maybe gm3
>will be running well enough soon that we can try some tests to see the
>difference in cost with our collector.

That would be very interesting.

If we get threads running in Scheme-48 soon, we may try a similar experiment
with Scheme.   (Ideally, within the next month so it can go in our
caching paper for LFP... here's hoping.)

  -- Paul
-- 
| Paul R. Wilson, runtime environmentalist        wilson@cs.utexas.edu        |
| U. of Texas Computer Sciences Dept.             voice: (512) 471-9555       |
| Taylor Hall 2.124, Austin, TX 78712-1188        fax:   (512) 471-8885       |


======================================================================== 22 ===
Date:    7 Mar 92 17:52:33 GMT
From:    doug@sni.ca (Doug Moen)
Subject: Re: Is there a definitive "definition of Modula-3"?

geb@amber.Rational.COM (Gary Barnes) writes:
>>Does the language have a generally agreed upon definition yet?

chased@rbbb.Eng.Sun.COM (David Chase) writes:
>Yes -- Harbison's book may be correct already, but I believe that
>Nelson's is supposed to be The Truth.

>>These two references describe related but distinctly different
>>languages and they both contain noticable holes, ambiguities, and
>>contraditions about the edges and hard semantic rules of the
>>language.  ... Is there a group
>>working on making a standard for it (ala IEEE, ANSI, ISO groups) or
>>working on writing a single definitive definition such as Ada's LRM?

>I hope like hell not.  I've got more faith in the people on the
>original committee ... than I do in any standards committee

>>Or is the language largely defined by what the SRC compiler accepts or
>>rejects?

>No, this is definitely not the case.

Well, in that case, there is a problem.
Nelson's book is an informal description of Modula-3; it is also incomplete
and ambiguous.  If I were writing a Modula-3 compiler, I would not be able
to do so strictly from reading Nelson's book.  In order to resolve ambiguities
in the language description, I would have to experiment with the SRC compiler
to see what it did, or I would have to obtain clarifications from the
language designers.  So the Modula-3 "language definition" resides partly
in Greg Nelson's book, partly in the behaviour of the SRC compiler, and
partly in the minds of the language designers.  This situation is workable
for now, because the Modula-3 community is small and friendly.  If Modula-3
is to grow past its current stage, then either it will need to have a
complete, unambiguous formal definition and reference manual that can be
consulted as the final authority on what is or is not legal Modula-3,
or there will be a "tower of babel" effect with different compilers
implementing different variants of the language, with the consequent
portability problems that that will entail for users of the language.

Actually, the tower of babel effect will happen anyway (as it has for C).
But the existence of the ANSI C Standard means that I can at least complain
to my compiler vendor when they violate the standard.

I agree with David Chase's comments about standards committees.  I certainly
don't like what the ANSI committee did to the C language.  All the more
reason for the Modula-3 language designers to produce a complete, unambigous
and definitive description of the language (using formal description mechanisms
where possible), before a committee of compiler vendors attempts to do the
job for them.
-- 
Doug Moen | doug@sni.ca | uunet!snitor!doug


======================================================================== 23 ===
Date:    8 Mar 92 15:38:24 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: Is there a definitive "definition of Modula-3"?

>>>>> On 7 Mar 92 17:52:33 GMT, doug@sni.ca (Doug Moen) said:

>>Or is the language largely defined by what the SRC compiler accepts or
>>rejects?

>No, this is definitely not the case.

Doug> Well, in that case, there is a problem.  Nelson's book is an informal
Doug> description of Modula-3; it is also incomplete and ambiguous.  If I were
Doug> writing a Modula-3 compiler, I would not be able to do so strictly from
Doug> reading Nelson's book.  In order to resolve ambiguities in the language
Doug> description, I would have to experiment with the SRC compiler to see
Doug> what it did, or I would have to obtain clarifications from the language
Doug> designers.  So the Modula-3 "language definition" resides partly in Greg
Doug> Nelson's book, partly in the behaviour of the SRC compiler, and partly
Doug> in the minds of the language designers.

Actually, there are fewer ambiguities than I first thought. When we dug in to
implement GNU Modula-3 (gm3) we went through the language definition carefully
and there were indeed a few points where we were confused. Ultimately I think
that Nelson's book (or the previous definitions) were not so much ambiguous as
difficult to understand in a few places. We obtained clarification from Greg,
et al., and a few additional programming examples would have straightened out
the difficulties we had. Short of a formal definition such as that for ML, the
Vienna definition of PL/1, or the Van Wijngarten (sp?) grammars of Algol-68, I
think the language designers have done a good job of language definition. (I
may not always agree with their choices, but that's a different matter.)

It could be that there are places where an implementor was deliberately given
freedom and it bothers you, e.g., checked run-time exceptions. The point here
is that though the SRC compiler does it one way, gm3 could legally do it
another way, and programs that depend on a specific behavior are wrong, though
compielrs are not necessarily required to detect such situations and warn the
programmer. While this may not always make for happy programmers, the
technology is not there (or perhaps we could say even if it is, it's not cost
effective to apply it) to do the checks, and because different machines,
operating systems, etc., do things different ways, there are points on which
it is inappropriate for the language designers to force a particular
implementation.

There *will* be differences in implementation between SRC M3 and gm3, but we
certainly intend that correct programs exhibit the same behavior in both
language systems.

Finally, of course there are probably *some* errors and ambiguities in the
Nelson book's definition. Heck, we found a minor error having to do with
whether a particular token was a keyword or reserved word (it got on the wrong
list), and we certainly found a few places that were hard for us to
understand. This leads me to agree that there needs to be a mechanism for
clarification and correction of the language definition -- possibly some
language designer approved "errata" or "addenda" that one can acquire via
anonymous ftp, etc. Further, if the language comes into wider use, the
community will undoubtedly interact with the designers to consider real
language changes and enhancements. I think the designers envision occasional
meetings of the most interested parties at which such topics can be discussed,
along the lines of an annual M3 users/implementors group meeting.

But PLEASE don't claim that the language should be defined by the book
definition plus the SRC compiler! We're working on a different compiler, and
he SRC folks will admit (I believe) that the SRC compiler does not always
implement the language as defined (what about integer overflow?).

Well, enough soapbox, Eliot; back to work!
--

		J. Eliot B. Moss, Assistant Professor
		Department of Computer Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu


======================================================================== 24 ===
Date:    Sun, 8 Mar 1992 13:35:00 PST
From:    David Goldberg <goldberg@parc.xerox.com>
Subject: Re: Is there a definitive "definition of Modula-3"?

Eloit Moss says:

      the SRC compiler does not always
      implement the language as defined (what about integer overflow?).

I hate to pick nits, but the SRC compiler is correct with respect to
integer overflow.  As explained on page 54 of "Systems Programming
with Modula-3", detecting integer overflow is not required.

	David Goldberg
	goldberg@parc.xerox.com


======================================================================== 25 ===
Date:    Mon, 9 Mar 92 08:29:47 PST
From:    kalsow@src.dec.com (Bill Kalsow)
Subject: Re: Is there a definitive "definition of Modula-3"?

In article <1992Mar7.175233.17378@sni.ca>, doug@sni.ca (Doug Moen) writes:
> Nelson's book is an informal description of Modula-3; it is also incomplete
> and ambiguous.

The ambiguities that exist in Greg's book are errors.  If you'll point
them out, we'll gladly fix them.

When the SRC Modula-3 compiler disagrees with Greg's book, the compiler
is in error.  Again, please let us know and we'll fix it.

Send bug reports to m3-request@src.dec.com.

 Thanks,
  - Bill Kalsow


======================================================================== 26 ===
Date:    9 Mar 92 19:03:36 GMT
From:    mayor@faraday.ece.cmu.edu (Gilberto S. Mayor)
Subject: Looking for Public Domain Modula3 compiler

Hi,

I  need a public-domain Modula-3 compiler.
Does anyone know any site where I can get one (both UNIX and PC
versions) ?
Thanks in advance for all the responses,
'
Gilberto Mayor


======================================================================== 27 ===
Date:    Mon, 9 Mar 92 21:24:11 GMT
From:    chambers@klamath.cs.washington.edu (Craig Chambers)
Subject: Re: Is there a definitive "definition of Modula-3"?

In article <1992Mar9.162640.9346@sni.ca>, doug@sni.ca (Doug Moen) writes:
|> >Eloit Moss says:
|> >
|> >      the SRC compiler does not always
|> >      implement the language as defined (what about integer overflow?).
|> 
|> David Goldberg <goldberg@parc.xerox.com> writes:
|> >I hate to pick nits, but the SRC compiler is correct with respect to
|> >integer overflow.  As explained on page 54 of "Systems Programming
|> >with Modula-3", detecting integer overflow is not required.
|> 
|> I've read page 54 over several times; it says nothing of the sort in
|> my copy.  Is there a new, revised 2nd edition of Systems Programming
|> with Modula-3?
|> -- 
|> Doug Moen | doug@sni.ca | uunet!snitor!doug

I just got my Nelson book, so I looked this up.  Overflow checking is
controlled by the operations of the FloatMode interface (pp. 75-77).
It appears possible for a legal implementation to ignore integer
overflow (and other exceptions) and not support re-enabling this
checking.  See the SetBehavior and GetBehavior procedures.

-- Craig Chambers


======================================================================== 28 ===
Date:    Mon, 9 Mar 1992 16:26:40 GMT
From:    doug@sni.ca (Doug Moen)
Subject: Re: Is there a definitive "definition of Modula-3"?

>Eloit Moss says:
>
>      the SRC compiler does not always
>      implement the language as defined (what about integer overflow?).

David Goldberg <goldberg@parc.xerox.com> writes:
>I hate to pick nits, but the SRC compiler is correct with respect to
>integer overflow.  As explained on page 54 of "Systems Programming
>with Modula-3", detecting integer overflow is not required.

I've read page 54 over several times; it says nothing of the sort in
my copy.  Is there a new, revised 2nd edition of Systems Programming
with Modula-3?
-- 
Doug Moen | doug@sni.ca | uunet!snitor!doug


======================================================================== 29 ===
Date:    10 Mar 92 01:04:18 GMT
From:    thor@asgard.mty.itesm.mx (Antonio Quesada-Duarte)
Subject: README File found in gatekeeper

Hi there.
I've just FTP'ed the modula3 sources found in gatekeeper.dec.com in  
pub/DEC/modula3/m3-2.0
Among other things, there is a README file coded in some strange page  
formatting language.
Does anybody in netland know what should i use to decode it?
I've tried using TeX but it didn't work (maybe i did something wrong).
Any help will be greatly appreciated.

Thanks a lot.

>From Monterrey, MEXICO:
Antonio Quesada-Duarte


======================================================================== 30 ===
Date:    10 Mar 92 03:26:18 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: Looking for Public Domain Modula3 compiler

Do you really mean public domain, or do you mean you don't have to pay for it?
Public domain means anybody can do anything with it, which is not true of a
lot of free software, including most of the GNU stuff.

To answer your question, you can pick up the SRC M3 compiler from
gatekeeper.dec.com in pub/DEC/Modula-3; *read its license agreement*! Sometime
we'll get our GNU M3 compiler done and you'll have a second source. SRC M3
runs on many Unix systems. There is no PC version of M3 yet. And guess what:
all this info is in the FAQ for this news group, which you could have gotten
by perusing the archives (on gatekeeper.dec.com, and probably other places,
too) ....						Eliot Moss
--

		J. Eliot B. Moss, Assistant Professor
		Department of Computer Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu


======================================================================== 31 ===
Date:    Mon, 9 Mar 92 18:39:57 PST
From:    muller@src.dec.com (Eric Muller)
Subject: Re: README File found in gatekeeper


Here is a plain text translation:

What is available
=================

SRC Modula-3 is distributed via anonymous ftp from gatekeeper.dec.com.
The distribution is in a set of compressed files in the directory
named pub/DEC/Modula-3/m3-2.0.  The files are of the form
archive-version.tar.Z; in the rest of the chapter, we will speak of
the archive archive and forget the version numbers.

The archives boot.<architecture> are used to build and install m3make,
a driver and a compiler.  These programs are built from intermediate C
files that are architecture specific; you need to get the archive(s)
corresponding to the architecture(s) on which you want to install SRC
Modula-3.  The supported architectures are:

Arch   | Hardware             | OS                |     build       | install
       |                      |                   | disk  | cpu     | disk
------------------------------------------------------------------------------
AIX386 |                      | AIX/PS2           |       |         |      
AP3000 | Apollo DN4500        | Domain/OS 10.2    |       |         |      
ARM    | Acorn R260           | RISC iX 1.21      |       |         |      
DS3100 | DECstation 5000/200  | Ultrix 4.2        | 23170 |  8 +  7 | 2758 
HP300  | HP 9000/300          | HP-UX 7.0         |       |         |      
IBMR2  | IBM RISC System/6000 | AIX 3.1           |       |         |      
IBMRT  | IBM RT               | IBM/4.3 (AOS 4.3) |       |         |      
SPARC  | Sparcstation-1       | SunOS 4.1.x       |       |         |      
SUN3   | Sun 3/?              | SunOS ?           |       |         |      
UMAX   | Encore Multimax      | UMAX 4.3 (R4.1.1) |       |         |      
VAX    | VAX 8800             | Ultrix 4.2        |       |         |      


Each of these archives is about 4000 kilobytes.  The column ``Build''
indicates the resources you need to build the two programs: ``disk''
is the amount of disk space (in kilobytes), ``cpu'' is the amount of
user and system cpu time (in minutes).  The column ``Install''
indicates the amount of disk space that will be permanently used after
the installation is done (in kilobytes).

The other archives contain Modula-3 source files for various libraries
and programs.

        File     |     Build    | Inst | Contents
Name      | size | disk  |  cpu | disk |
-------------------------------------------------------------------------------
libm3     | 1096 | 20374 |  8+4 | 5742 | base library
X11R4     |  128 |  2906 |  4+1 | 1057 | binding interfaces to X11R4
trestle   |  416 | 13245 | 14+3 | 4048 | Trestle window system, needs  X11R4
pinecreek |  312 |   842 |  1+0 |   89 | Pine Creek Library
bicycle   |      |       |      |      | library for Trestle card games
demos     |   80 | 10446 |  4+1 |    0 | demo programs, needs trestle & bicycle
data      |   40 |  2693 |  2+1 |  856 | some generic container types 
color     |   53 |  1559 |  1+1 |  483 | color manipulation 
sx        |  168 |  2294 |  1+0 |  413 | Lisp-like S-expressions 
tools     |  184 |  1746 |  1+0 |  548 | development tools 
compiler  |  360 | 11255 | 12+5 |    0 | compiler
driver    |   66 |       |      |    0 | driver
m3make    |   44 |       |      |    0 | make for Modula-3
doc       |      |       |      |      | the documentation for SRC Modula-3
tests     |  336 |       |      |    0 | ``validation'' tests 


The column ``File Size'' is the size (in kilobytes) of the compressed
tar file.  The colum ``Build'' indicates the resources you need to
build and install these pieces of sources: ``disk'' is the amount of
disk space (in kilobytes), ``cpu'' is the amount of user and system
cpu time (in minutes).  The column ``Install'' indicates the amount of
disk space that will be permanently used after the installation is
done; if you want to keep the sources around, you will need more
space.  These time and sizes have been measured on a DECstation
5000/200 running Ultrix 4.2; other architectures may have different
requirements.

You need to build and install libm3 to have a useful system, but all
the other pieces are optional.

The m3make and doc archives are also contained in the boot archives.


Getting SRC Modula-3
====================

In the following, $ is the shell prompt and ftp> is the ftp prompt. To
get SRC Modula-3:


1. Make sure that you have enough disk space using the tables above.
  
2. Create a fresh directory for the software and go there. Path
   names below are relative to that directory, and it will be called the
   top-level directory:
 
    $ mkdir  top-level 
    $ cd  top-level 

3. Open an connection with gatekeeper.dec.com [16.1.0.2]; give
   anonymous for the name and your login id for the password:
 
    $ ftp gatekeeper.dec.com
    Connected to gatekeeper.dec.com.
    ...
    Name (gatekeeper.dec.com): anonymous
    Password (gatekeeper.dec.com:anonymous):  your name@ your machine
    ...

4. Change to the proper directory:

    ftp> cd pub/DEC/Modula-3/m3-2.0

5. Set the transmission type to binary:

    ftp> type binary

6. Get the files you want:

    ftp> get boot.<architecture>-<version>.tar.Z
    ftp> get libm3-<version>.tar.Z 
    ftp> get ... 


7. Close the connection:

    ftp> quit

8. Uncompress and extract the files:

 
    $ zcat boot.<architecture>-*.tar.Z | tar xpof - 
    $ zcat libm3-*.tar.Z +|+ tar xpof - 
    $ ...

   The  arguments specify the following options:

      x: extract the files from the  file to the current directory 
      p: restore files to their original modes 
      o: override the original ownership, this makes you the owner of
         the files 
      f: use the following argument (e.g  -) as the input
          file;  - as the input file means  stdin 

   You can add the v option to see what is going on.

9. At this point you may delete the archives to save space (the
   disk requirements indicated above assume that you do delete these files):
 
    $ rm *.tar.Z


Installation procedure
======================

See the toplevel README for what do.



Note
====

The 2.03 top-level m3makefile does not work on SPARC.  Apply the
following path after you have uncompressed and extracted all the
archives:


*** m3makefile.old	Fri Feb  7 23:52:18 1992
--- m3makefile	Fri Feb  7 23:53:15 1992
***************
*** 145,146 ****
--- 145,147 ----
  #define machine_iter(x)                                                     @
@\
+ all_##x::                                                                   @
@\
  	@for d in $(MACHINES); do \                                         @@\
***************
*** 149,158 ****
  
! all_cross::
! 	machine_iter (cross)
! all_bootstrap_both::
! 	machine_iter (bootstrap_both)
! all_bootstrap_scratch::
! 	machine_iter (bootstrap_scratch)
! all_pack::
! 	machine_iter (pack)
  
--- 150,155 ----
  
! machine_iter (cross)
! machine_iter (bootstrap_both)
! machine_iter (bootstrap_scratch)
! machine_iter (pack)


-- 
Eric.



======================================================================== 32 ===
Date:    10 Mar 92 16:08:18 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: Modula-3 News #3 call for articles

I am beginning to prepare the third issue of "Modula-3 News," a
Modula-3 newsletter, and am requesting material to include.

If you are teaching Modula-3 or writing software with it or developing
Modula-3 products or services, send me a brief description. Anything
related to Modula-3 is welcome. I typically edit all submissions
(except ads), but will let you review the edited version.

I hope that this issue will be the first one with real advertisements for
Modula-3 products and services. (No charge for including them.)

This is a paper newsletter, distributed free worldwide to people on
our mailing list and at various conferences, etc. Plain-text
electronic versions have also been distributed, without the photos,
etc.  If you would like to be on the mailing list and/or receive back
issues, send me your name and address.

Please submit material by the end of March, as I would like to send out
the next issue in April, before schools begin to let out for the summer.

Sam Harbison 
Pine Creek Software; Suite 300; 305 South Craig Street; Pittsburgh, PA 15213;
USA. Phone&FAX: +1 412 681 9811. E-mail: harbison@bert.pinecreek.com.


======================================================================== 33 ===
Date:    11 Mar 92 13:53:42 GMT
From:    laverman@cs.rug.nl (Bert Laverman)
Subject: SRC Modula-3 on the HP 9000/800


Dear All,
  Has anybody ever contemplated porting SRC-m3 to the HP 9000/800 system?
I know there is a 9000/300 port, but the 800 is a RISC monster...

  I'm definately _not_ a 9000/800 wizard, but would be _very_ grateful
for any tips and hints.

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

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


======================================================================== 34 ===
Date:    12 Mar 92 10:49:57 GMT
From:    btaplin@silver.ucs.indiana.edu (Brad Taplin)
Subject: Windows development under Mod3?


	Hello. I have considered Pascal and Smalltalk as serious
	alternatives to C, which seems to me unsuited to Windows.
	Smalltalk is supposed to be good but requires enormous
	resources (say netters) and has a steep learning curve.
	Turbo Pascal might work, but supposedly has limitations.
	Actor 4.0 at $99 is something I haven't examined much.

	So, is there anything Mod3 can't do very well? Can it
	deal with DLLs and UAEs? Bugs? I wanna develop on the
	side with something more suited to prototyping than C
	but still able to produce clean, fast GUI executables.
	Please recommend sources. Will this require the SDK?

	Gotta run. Thanks for the info.


======================================================================== 35 ===
Date:    12 Mar 92 16:26:23 GMT
From:    abbasi@star.enet.dec.com (Nasser ABBASI)
Subject: Modula-3 For scientific/mathematical programming ?


in comp.lang.fortran there is some talk about fortran vs this language and 
that language, and i thought of Modula-3, has anyone looked at modula-3 from 
the point of view of using it for scientific programming? what's their 
experience with it in this regard? 

sorry if this sounds like a very general question.

/nasser


======================================================================== 36 ===
Date:    12 Mar 92 14:25:20 GMT
From:    dagenais@vlsi.polymtl.ca (Michel Dagenais)
Subject: Modula 3 and the Andrew system

The CMU Andrew system just released newsletter includes a paragraph about
Modula 3. FYI:

> \bold{Modula-3 } -  Although not the work of the Consortium, a related group
> is developing a Modula-3 interface for ATK.  The goal is bi-directional:
> modula-3 objects will be able to invoke methods of ATK objects and ATK
> objects will be able to call methods of modula-3 objects.  Each will be able
> to have pointers to the other.  This magic is possible because the run-time
> representations were originally close enough that the ATK object
> representation could be modified sufficiently to match the modula-3 model.
> The result is that future development can be done in the modula-3 environment
> with automatic storage management, exceptions, an inter-module definition
> language sufficient to support strong typing in function calls, and numerous
> other pleasantries.  (Unfortunately, the ATK portion of the system will still
> not have storage management.)
--
---------------------------------------------------------------------

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

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


======================================================================== 37 ===
Date:    Thu, 12 Mar 92 17:37:13 +0100
From:    Piet van Oostrum <piet@cs.ruu.nl>
Subject: Re: Modula-3 on HP300 vs HP700

>>>>> SCHWEIZER@eldi.epfl.ch (PS) writes:


PS>        Dear Sir

PS>    I got the Modula-3 system from gatekeeper.dec.com and try to install you
r HP300 version on a HP700.

PS> Unfortunatly, the 700 serie has not too much ion common with the 300
PS> serie.  After some bad tricks, I got the driver and compiler compiled,
PS> but both crashes in the early steps of the library initialisation,
PS> namely in RTMain__installSignalsHandler().

PS>   Please could you confirm that it is really needed to cross-compile,
PS> i.e. there is no way to just try to recompile the c-code.

PS>    Perhaps could you comment the message I posted :

PS> Subject:      Modula-3 on HP900/700
PS> Date:         12 Mar 92 14:06:43 GMT
PS> From:         SCHWEIZER@eldi.epfl.ch (NICOUD)
PS> Organization: Ecole Polytechnique Federale de Lausanne, Dpt d'informatique


PS>    Dear Modula enthousiasts

PS>   One of the last message asked about a port to the HP 800 series.

PS> I am trying toport on the HP 700 series (model 720) which is said to be
PS> highly compatible with the 800 serie.

PS> I started from the HP300 version available on gatekeeper.dec.com, but
PS> have not succeded.  First, just avoid to compile the m3make, it is not
PS> easy, and perhaps not really needed for a first try.
==============================
This problem is probably caused by the make program. A solution is to use
the gnu make. By the way this problem also appears on the HP300.
==============================

PS> BUT, there is one file in assembly language : alloca.s
==============================
This can be circumvented by including libPW (-lPW) on the loader commands.
==============================

PS> On the link command, note the -lBSD to link with the BSD library, required
PS> by the sigvec subroutine.

PS> However, m3 crashes after 10 instructions. In RTMain__InstallSignalsHandler
(),
PS> at the time he tries to clear (initialize) a sigvec variable. He uses
PS> _ZERO( 40, vs) to clear 40 bytes. So it seems that the size of variables ar
e
PS> determined by the compiler DEPENDING ON THE TARGET (perhaps by parsing some
 .h
PS> files for the specific target ?)
==============================
This is right
==============================

I have found why this problem occurs. It should probably also give problems
on HP9000/300 systems.

There is a wrong definition in Usignal.i3. The definition of sigvec is:

	
  struct_sigvec  = RECORD
    sv_handler: SignalHandler;     (* signal handler *)
    sv_mask:    sigset_t;          (* signal mask to apply *)
    sv_flags:   int;               (* see signal options below *) END;


It should be

	
  struct_sigvec  = RECORD
    sv_handler: SignalHandler;     (* signal handler *)
    sv_mask:    int;	           (* signal mask to apply *)
    sv_flags:   int;               (* see signal options below *) END;

I think it would be savest if somebody with a good compiler (e.g. the
developers) recompiled the thing. I can try to recompile, but I don't know
if my compiler (with the above bug) is good enough.

Piet* van Oostrum, Dept of Computer Science, Utrecht University,
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands.
Telephone: +31 30 531806   Uucp:   uunet!mcsun!ruuinf!piet
Telefax:   +31 30 513791   Internet:  piet@cs.ruu.nl   (*`Pete')


======================================================================== 38 ===
Date:    12 Mar 92 14:06:43 GMT
From:    SCHWEIZER@eldi.epfl.ch (NICOUD)
Subject: Modula-3 on HP900/700


   Dear Modula enthousiasts

  One of the last message asked about a port to the HP 800 series.

I am trying toport on the HP 700 series (model 720) which is said to be
highly compatible with the 800 serie.

I started from the HP300 version available on gatekeeper.dec.com, but have not
succeded.
First, just avoid to compile the m3make, it is not easy, and perhaps not really
needed for a first try.

the other way to go is:

  cd driver/boot-HP300
  cc -cg *.c
  cc -om3 *.o -lBSD

  cd ..
  cd compiler/boot-HP300
  and also compile in the same way

BUT, there is one file in assembly language : alloca.s

you can try to create instead a file alloca.c
with inside :
#include <stdlib.h>

void *alloca( size)
int size;
{
  return malloc( size );
}

On the link command, note the -lBSD to link with the BSD library, required
by the sigvec subroutine.

So, everything compiles and links smoothly.

However, m3 crashes after 10 instructions. In RTMain__InstallSignalsHandler(),
at the time he tries to clear (initialize) a sigvec variable. He uses
_ZERO( 40, vs) to clear 40 bytes. So it seems that the size of variables are
determined by the compiler DEPENDING ON THE TARGET (perhaps by parsing some .h
files for the specific target ?)

   Can any body confirm/inform ?

Aside this, I would greatly appreciate if somebody has already done the port
(I am not a U**X guru)

   Thanks in advance

         Philippe Schweizer
                        
 schweize@eldi.epfl.ch

tel 011 41 21 801 72 71         fax 011 (41) (21) 802 13 00     (switzerland)


======================================================================== 39 ===
Date:    12 Mar 92 19:29:07 GMT
From:    chased@rbbb.Eng.Sun.COM (David Chase)
Subject: Re: Modula-3 For scientific/mathematical programming ?

In article <34151@nntpd.lkg.dec.com> abbasi@star.enet.dec.com (Nasser ABBASI) w
rites:
>has anyone looked at modula-3 from the point of view of using it for
>scientific programming? what's their experience with it in this regard? 

Little experience, but the ability to declare a parameter to be a
multi-dimensional open array was provided specifically to be friendly
to scientific programming.  Thus, one can say:

PROCEDURE GEPP (VAR a:ARRAY OF ARRAY OF FLOAT;
                VAR pivot : ARRAY OF INT; 
                VAR condition_number : FLOAT)

Maniacal array mutiliation in the style of Fortran is not permitted,
but you are not as constrained as you are in C or Pascal or Modula-2.
Subarrays can be taken, but all you get are subsections of the leading
(row) dimension -- you cannot use subarrays to tile a matrix.  This
was more or less the point of compromise.  By keeping that
restriction, multi-dimensional open arrays are never more expensive
than their Modula-2 equivalent (which is often "illegal", or "infinite
cost").

"Obviously" all the descriptor manipulation is amenable to classical
optimization techniques, so if there is ever sufficient demand for an
optimizing Modula-3 compiler, it will not be an insurmountable task to
make Fortran-in-Modula-3 run well.

Nested functions are another big plus for numerical work that is
unavailable in either F77 or C.  I also found that exception handling
was quite a handy tool when I wrote a little dinky Newton-solver -- if
it fails to converge, it raises an exception.

One thing that is missing that I still hope to see in the language
(someday) is a declarations of

  VAR IN
  VAR OUT

and possibly
  
  VAR IN_OUT (* Like VAR, but different aliasing rules. *)

The intent is that these parameters have "Fortran aliasing rules",
which can be translated to "either by reference or value-result, and
if your program can tell the difference, then it is illegal".  This
has obvious benefits for systems that wish to support RPC (copy-in,
copy-out), and obvious (to Fortran optimizer-writers) benefits for
code restructuring optimizations that increase cache locality,
parallelism, and register reuse.  I believe that these additional
keywords could be added with little damage to the existing legal
prorgams -- "IN" is already a keyword, and if we wanted we could say
"VAR RETURN" instead of "VAR OUT" to avoid accidental clashes with
legal programs.  (However, one should not get too cute with this
game.)

Those are about the only concrete proposals.  There's been some
muttering from friends of mine about the usefulness of something like
"FORALL", meaning "run all the iterations in any order, using threads
if it helps, but not if it doesn't", but a definite proposal never
came out of it.

David Chase
Sun


======================================================================== 40 ===
Date:    Thu, 12 Mar 1992 14:07:25 PST
From:    David Goldberg <goldberg@parc.xerox.com>
Subject: Re: Modula-3 For scientific/mathematical programming ?

Yes, I have looked at using Modula-3 for scientific programming. 
Overall, it is my (highly biased) opinion that Modula-3 is almost as
good as FORTRAN for scientific computing.

First of all, there are the general plusses of Modula-3: strong typing,
interfaces, etc.

For mathematical uses, some of the advantages are (1) generics, so that
you can generate the single and double precision versions of programs
automatically, (2) three float-types, so that you can access extended
precision (on machines which have it) in a portable way, (3) good
control over floating-point arithmetic.  There are built-in
floating-point interfaces which let you easily get the values of machine
epsilon, smallest representable number, etc.;  a standard (i.e. required
interface) way to access IEEE arithmetic (such as rounding modes) on
machines that have it, ability to query the type of arithmetic being
used, and the ability to query (and manipulate) how a machine handles
exceptions like overflow.  Thus programs can deal with rounding,
overflows, and underflows in a portable way (portable across machines
that implement Modula-3, that is).

The disadvantages are much like C, Pascal, etc:  (1) no built-in complex
type, (2) no built-in exponential function (3) arrays don't match
FORTRAN (they are zero-based and stored by row, not column) (4) there
isn't a standard required math library for transcendentals (5) no simple
way to specify floating-point constants exactly (i.e. in binary).   
However, unlike C and Pascal, Modula-3 does handle functions that take
arbitrary-length arrays as arguments:  the size of an array argument can
be instantiated at call-time.

There is also a disadvantage of the current Modula-3 compiler from SRC, which
is that it generates C, and thus has to work around C's propensity to
automatically promote float to double.

	David Goldberg
	goldberg@parc.xerox.com




======================================================================== 41 ===
Date:    Thu, 12 Mar 92 11:53:32 PST
From:    muller@src.dec.com (Eric Muller)
Subject: Re: Modula-3 on HP300 vs HP700

We are going to make a release either tomorrow or monday (2.04).  I
will send a message with the details at that time, but here are some
news for the HP world.

> PS> BUT, there is one file in assembly language : alloca.s
> ==============================
> This can be circumvented by including libPW (-lPW) on the loader commands.

We got rid of alloca in the new version.

> There is a wrong definition in Usignal.i3. The definition of sigvec is:
> 
> 	
>   struct_sigvec  = RECORD
>     sv_handler: SignalHandler;     (* signal handler *)
>     sv_mask:    sigset_t;          (* signal mask to apply *)
>     sv_flags:   int;               (* see signal options below *) END;
> 
> 
> It should be
> 
> 	
>   struct_sigvec  = RECORD
>     sv_handler: SignalHandler;     (* signal handler *)
>     sv_mask:    int;	           (* signal mask to apply *)
>     sv_flags:   int;               (* see signal options below *) END;
> 

Fixed.  I suspect that the same change should be made to the strct_sigaction 
type declaration that is just above it ?

-- 
Eric.



======================================================================== 42 ===
Date:    12 Mar 92 20:15:59 GMT
From:    kalakota@ut-emx.uucp (Ravi Kalakota)
Subject: O-O maintanence -- A myth ?


Easy maintenence in O-O environments -- A myth??

The two oft-cited advantages of O-Based and O-Oriented approaches have been 
code (and design) reuse and easy extensibility and modifiability. Code reuse 
has brought about substantial reduction in the size of new code that has to 
be generated and also the size of the overall system. As the code size 
becomes less, the complexity of the system increases dramatically.  
Does complexity affect maintenence? Probably not in a simple project.
But in a large system ...

Software maintanence usually takes anywhere between 60-90%  of the software 
budget, according to popular literature. Has O-O-P really affected this figure?
 I would like to gather information and data on this and your views 
(either pro/con).

Another important issue is that could be discussed is  -- 
whether  O-O-P is a strategic advantage versus a strategic necessity in 
today's business world.

Please e-mail your thoughts/views to me and I will summarize.


Ravi Kalakota

Centre for Information Systems Management
University of Texas at Austin

e-mail : kalakota@emx.utexas.edu


======================================================================== 43 ===
Date:    Thu, 12 Mar 92 12:30:21 PST
From:    muller@src.dec.com (Eric Muller)
Subject: Re: Modula-3 For scientific/mathematical programming ?

I suppose that the presence of three real types (REAL, LONGREAL and
EXTENDED), that are supposed to match IEEE types whenever possible,
will be useful.  Also, the standard floating point interfaces give
some access to the floating point runtime: for example, you can
specify that floating point exceptions should be mapped to Modula-3
exceptions.  The integration of these things in the language will
probably help a lot the portability of floating point programs.  Many
thanks to David Goldberg for designing these interfaces.

The current status of the implementations is not quite as nice.  SRC
Modula-3 2.04 (coming soon) implements these interfaces for DS3100 and
SPARC (the status is not yet thread-specific, but that should come
soon). 

-- 
Eric.



======================================================================== 44 ===
Date:    12 Mar 92 16:00:58 GMT
From:    piet@cs.ruu.nl (Piet van Oostrum)
Subject: Re: SRC Modula-3 on the HP 9000/800

>>>>> laverman@cs.rug.nl (Bert Laverman) (BL) writes:


BL> Dear All,
BL>   Has anybody ever contemplated porting SRC-m3 to the HP 9000/800 system?
BL> I know there is a 9000/300 port, but the 800 is a RISC monster...

BL>   I'm definately _not_ a 9000/800 wizard, but would be _very_ grateful
BL> for any tips and hints.

I have contemplated this (actually for the 700 which is very similar). I
will try this probably next week. Please note that a number of problems
have been  found with the HP version.
-- 
Piet van Oostrum <piet@cs.ruu.nl>


======================================================================== 45 ===
Date:    Fri, 13 Mar 92 11:41:55 +0100
From:    Piet van Oostrum <piet@cs.ruu.nl>
Subject: Re: Modula-3 on HP300 vs HP700

>>>>> muller@src.dec.com (Eric Muller) (EM) writes:

EM> We are going to make a release either tomorrow or monday (2.04).  I
EM> will send a message with the details at that time, but here are some
EM> news for the HP world.

EM> Fixed.  I suspect that the same change should be made to the strct_sigactio
n 
EM> type declaration that is just above it ?

No the sigaction should contain the sigset.

from signal.h:

   /* Structures used with POSIX signal facilities. */

#  ifdef _INCLUDE_HPUX_SOURCE
     typedef struct __sigset_t {
          long sigset[8];
     } sigset_t;
#  else /* not _INCLUDE_HPUX_SOURCE */
     typedef struct __sigset_t { 
	  long __sigset[8];
     } sigset_t;
#  endif /* _INCLUDE_HPUX_SOURCE */

   struct sigaction {
      void  (*sa_handler)(__harg); /* SIG_DFL, SIG_IGN, or pointer to a func */
      sigset_t   sa_mask;	   /* Additional set of signals to be blocked
				     during execution of signal-catching
				     function. */
      int	sa_flags;	  /* Special flags to affect behavior of sig */
   };


   struct sigstack {		/* Used with sigstack(). */
	char	*ss_sp;			/* signal stack pointer */
	int	ss_onstack;		/* current status */
   };

   struct sigvec {		/* Used with sigvec() and sigvector(). */
      void    (*sv_handler)(__harg);	/* signal handler */
      int	sv_mask;		/* signal mask to apply */
      int	sv_flags;		/* see below */
   };


By the way, I found why the HPUX make doesn't work with imake: This make
does not allow the use of comments in the rules. Some m3makefiles have #if
sections in the rules and cpp translate these into a # linenumber. So
ideally imake should filter out the # comment lines from the output of cpp.

Did you receive my earlier comments about the HP port?

Anyway, here is what I collected thus far:

1. compiler error (register allocation error).
   This is a serious compiler error in HP-UX 8.0. In some cases it goes
   away by using -O (on AutoFlushWr.m in the compiler/driver and libm3),
   but in trestle there are cases where this doesn't help.
	Use -O in m3makefiles and m3make/toplevel.tmpl
2. -lBSD missing
3. config says INCLDIR, m3makefile says $(INCL).
4. test does not exist in csh (used in m3make.model). Better replace with 
	if (-d)...
   For now I created the following shell script called test:
------------------------------------------------------------------------
#! /bin/sh
test "$@"
------------------------------------------------------------------------
5. alloca.s is better than the built-in alloca (from libBSD or libPW?) but
only on HP9000/300. Otherwise use -lPW.

6. dtoa.c must be updated. It should define #define IEEE_MC68k.

Here are the diffs that I used for the compiler:
(The dtoa.c thing and the Floating Point interfaces have to be looked into
more seriously I think, but for the moment they might suffice.)
libm3 needs also a -O for AutoFlushWr. I am not happy with this because I
don't trust the -O. I have seen too many programs fail with -O and succeed
with +O1, but this compiler bug also bites with +O1.

Good luck!
------------------------------------------------------------------------
*** m3make/config/config.~1~	Thu Feb 13 14:22:33 1992
--- m3make/config/config	Thu Mar 12 17:25:25 1992
***************
*** 114,120 ****
  KEEP_LIBRARIES_RESOLVED = 0
  
  /* We don't want to use the predefined CFLAGS */
! CFLAGS = -O
   
  /* Some versions of make(1) let us specify the shell to use. In any
     case, we want sh */
--- 115,121 ----
  KEEP_LIBRARIES_RESOLVED = 0
  
  /* We don't want to use the predefined CFLAGS */
! CFLAGS = 
   
  /* Some versions of make(1) let us specify the shell to use. In any
     case, we want sh */
*** m3make/toplevel.tmpl.~1~	Wed Feb  5 22:11:06 1992
--- m3make/toplevel.tmpl	Tue Feb 25 12:39:26 1992
***************
*** 17,23 ****
  M3        = $(BIN_USE)/m3
  		/* $(BIN_USE) to go around a bug in Ultrix 4.2 make */
  M3FLAGS   = -w1 -make -why
! M3OPT     = -g
  M3DEFPATH =
  M3LIBPATH =
  DO_M3     = $(M3) $(M3FLAGS) $(M3OPT) $(M3DEFPATH) $(M3LIBPATH)
--- 17,23 ----
  M3        = $(BIN_USE)/m3
  		/* $(BIN_USE) to go around a bug in Ultrix 4.2 make */
  M3FLAGS   = -w1 -make -why
! M3OPT     = -O
  M3DEFPATH =
  M3LIBPATH =
  DO_M3     = $(M3) $(M3FLAGS) $(M3OPT) $(M3DEFPATH) $(M3LIBPATH)
*** m3make/makefile.~1~	Sun Feb  2 07:50:31 1992
--- m3make/makefile	Thu Mar 12 17:26:28 1992
***************
*** 1,3 ****
--- 1,4 ----
+ SHELL=/bin/sh
  all:: imake call_m3make
  
  imake: imake.c config/config
*** driver/boot-HP300/m3makefile.objs.~1~	Thu Feb  6 11:13:39 1992
--- driver/boot-HP300/m3makefile.objs	Thu Feb 13 15:01:41 1992
***************
*** 228,230 ****
--- 228,233 ----
      Usignal_m.o \
      Utypes_m.o \
      _m3main.o
+ 
+ AutoFlushWr_m.o: AutoFlushWr_m.c
+ 	IFS=' $(SEP)'; $(PASS1) -c -O AutoFlushWr_m.c
*** driver/boot-HP300/dtoa.c.~1~	Tue Feb  4 11:39:57 1992
--- driver/boot-HP300/dtoa.c	Thu Feb 13 16:22:50 1992
***************
*** 2,9 ****
  #define KR_headers
  #endif
  
! #ifndef IEEE_8087
! #define IEEE_8087
  #endif
  
  #include "dtoa.h"
--- 2,9 ----
  #define KR_headers
  #endif
  
! #ifndef IEEE_MC68k
! #define IEEE_MC68k
  #endif
  
  #include "dtoa.h"
*** driver/src/m3makefile.~1~	Thu Feb  6 10:28:34 1992
--- driver/src/m3makefile	Thu Feb 13 15:16:55 1992
***************
*** 32,38 ****
  all:: m3
  
  m3::  $(OBJS)
! 	IFS=' $(SEP)'; $(PASS2) -o m3 $(OBJS) -lm
  
  .c.o:
  	IFS=' $(SEP)'; $(PASS1) -c $<
--- 32,38 ----
  all:: m3
  
  m3::  $(OBJS)
! 	IFS=' $(SEP)'; $(PASS2) -o m3 $(OBJS) -lBSD -lm
  
  .c.o:
  	IFS=' $(SEP)'; $(PASS1) -c $<
*** compiler/boot-HP300/m3makefile.objs.~1~	Thu Feb  6 11:12:15 1992
--- compiler/boot-HP300/m3makefile.objs	Thu Feb 13 15:02:44 1992
***************
*** 561,563 ****
--- 561,566 ----
      Usignal_m.o \
      Utypes_m.o \
      _m3main.o
+ 
+ AutoFlushWr_m.o: AutoFlushWr_m.c
+ 	IFS=' $(SEP)'; $(PASS1) -c -O AutoFlushWr_m.c
*** compiler/boot-HP300/dtoa.c.~1~	Tue Feb  4 10:29:41 1992
--- compiler/boot-HP300/dtoa.c	Thu Feb 13 16:23:09 1992
***************
*** 2,9 ****
  #define KR_headers
  #endif
  
! #ifndef IEEE_8087
! #define IEEE_8087
  #endif
  
  #include "dtoa.h"
--- 2,9 ----
  #define KR_headers
  #endif
  
! #ifndef IEEE_MC68k
! #define IEEE_MC68k
  #endif
  
  #include "dtoa.h"
*** compiler/src/m3makefile.~1~	Thu Feb  6 10:29:17 1992
--- compiler/src/m3makefile	Thu Feb 13 15:17:10 1992
***************
*** 10,16 ****
  all:: m3compiler
  
  m3compiler::  $(OBJS)
! 	IFS=' $(SEP)'; $(PASS2) -o m3compiler $(OBJS) -lm
  
  .c.o:
  	IFS=' $(SEP)'; $(PASS1) -c $<
--- 10,16 ----
  all:: m3compiler
  
  m3compiler::  $(OBJS)
! 	IFS=' $(SEP)'; $(PASS2) -o m3compiler $(OBJS) -lBSD -lm
  
  .c.o:
  	IFS=' $(SEP)'; $(PASS1) -c $<
*** libm3/Csupport/src/HP300/dtoa.c.~1~	Thu Jan 30 07:08:38 1992
--- libm3/Csupport/src/HP300/dtoa.c	Thu Feb 13 16:23:35 1992
***************
*** 2,9 ****
  #define KR_headers
  #endif
  
! #ifndef IEEE_8087
! #define IEEE_8087
  #endif
  
  #include "dtoa.h"
--- 2,9 ----
  #define KR_headers
  #endif
  
! #ifndef IEEE_MC68k
! #define IEEE_MC68k
  #endif
  
  #include "dtoa.h"
------------------------------------------------------------------------

Piet* van Oostrum, Dept of Computer Science, Utrecht University,
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands.
Telephone: +31 30 531806   Uucp:   uunet!mcsun!ruuinf!piet
Telefax:   +31 30 513791   Internet:  piet@cs.ruu.nl   (*`Pete')



======================================================================== 46 ===
Date:    13 Mar 92 11:02:06 GMT
From:    qs101@cl.cam.ac.uk (Quentin Stafford-Fraser)
Subject: Re: Windows development under Mod3?

In article <1992Mar12.055006.7578@bronze.ucs.indiana.edu>,
btaplin@silver.ucs.indiana.edu (Brad Taplin) writes:

|> 	So, is there anything Mod3 can't do very well?

Err, yes. It won't run on a PC.

Please, someone, tell me I'm wrong...

 -----------------------------------
 Quentin Stafford-Fraser            
 Cambridge University Computer Lab  
 qs101@cl.cam.ac.uk
 Tel +44 223 334645
 -----------------------------------


======================================================================== 47 ===
Date:    13 Mar 92 15:45:31 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: Re: Windows development under Mod3?

In article <1992Mar13.110206.22438@cl.cam.ac.uk> qs101@cl.cam.ac.uk (Quentin St
afford-Fraser) writes:
>...
>Err, yes. It won't run on a PC.
>
>Please, someone, tell me I'm wrong...
>...

After having looked at SRC Modula-3 2.0's "bootstrap" structure and at
the next generation of PC tools (in particular, the 32-bit compilers
from Microsoft and Borland due summer/fall), I think a PC port of SRC
Modula-3 is now feasible.

An OS/2 port could begin as soon as IBM ships OS/2 2.0 this month,
since it will have a full 32-bit development environment.

So, if you're interested, get to work...

Sam Harbison 
Pine Creek Software; Suite 300; 305 South Craig Street; Pittsburgh, PA 15213;
USA. Phone&FAX: +1 412 681 9811. E-mail: harbison@bert.pinecreek.com.


======================================================================== 48 ===
Date:    13 Mar 92 16:01:59 GMT
From:    mar19@cl.cam.ac.uk (M.A. Ramage)
Subject: Re: Windows development under Mod3?

In article <1992Mar12.055006.7578@bronze.ucs.indiana.edu> btaplin@silver.ucs.in
diana.edu (Brad Taplin) writes:
>
>	Hello. I have considered Pascal and Smalltalk as serious
>	alternatives to C, which seems to me unsuited to Windows.
>	Smalltalk is supposed to be good but requires enormous
>	resources (say netters) and has a steep learning curve.
>	Turbo Pascal might work, but supposedly has limitations.
>	Actor 4.0 at $99 is something I haven't examined much.
>
>	So, is there anything Mod3 can't do very well? Can it
>	deal with DLLs and UAEs? Bugs? I wanna develop on the
>	side with something more suited to prototyping than C
>	but still able to produce clean, fast GUI executables.
>	Please recommend sources. Will this require the SDK?
>
>	Gotta run. Thanks for the info.

Well, there's a fundamental problem... There isn't yet a Modula-3 compiler for
the PC, and even when one comes out I doubt it'll be Windows compatible. 
I'd recommend Turbo Pascal for Windows, it's got lots of class libraries so you
can program reasonably efficiently without too much recourse to using the 
Windows Application Programming Interface (API) - though you might find it
necessary for some things. 

I entirely sympathise with you about disliking C, I think it's an abomination o
f
a language (and C++ isn't much better). TPW has its limitations, but it's 
probably the best development environment for Windows just now. 

----
Magnus Ramage     mar19@phx.cam.ac.uk
Undergraduate computer scientist but I'm not spotty honest guv.
I'm spending far too much time using Windows though...


======================================================================== 49 ===
Date:    13 Mar 92 21:50:41 GMT
From:    mbk@lyapunov.ucsd.edu (Matt Kennel)
Subject: Re: Modula-3 For scientific/mathematical programming ?

chased@rbbb.Eng.Sun.COM (David Chase) writes:
: In article <34151@nntpd.lkg.dec.com> abbasi@star.enet.dec.com (Nasser ABBASI)
 writes:
: >has anyone looked at modula-3 from the point of view of using it for
: >scientific programming? what's their experience with it in this regard? 

: Little experience, but the ability to declare a parameter to be a
: multi-dimensional open array was provided specifically to be friendly
: to scientific programming.

: <deleted>

: Those are about the only concrete proposals.  There's been some
: muttering from friends of mine about the usefulness of something like
: "FORALL", meaning "run all the iterations in any order, using threads
: if it helps, but not if it doesn't", but a definite proposal never
: came out of it.

Have you been reading the present thread in comp.lang.misc and
comp.lang.fortran?

A few people have been asking for a language that understands essentially
summation conventions and general index notation, as used in undergraduate
math.

So, in some sort of vague psuedocode:

	for i,j: C(i,j) = sum k : A(i,k) * B(j,k)

Which says C = A * Transpose(B) in a straightforward way, of course, assuming
it can figure out the array bounds for i,j,k, which is often not much
a problem.  (And the "sum" is an expression, not part of a statement).

And/or how about a new integer type INDEX, which makes the sums and foralls
implicit for all repeated indices?

This is a lollipop purely for the numerical community, but as even Fortran 90
doesn't do this,  it might enormously increase the base of appeal
for a new language.   All of a sudden, people who would have never bothered
to learn ("Oh it's just another silly CS poofta weenie DissertationLanguage")
will listen carefully.

I've stopped learning C++, thinking it's really ugly (even though I already
program in C these days), hoping that Modula-3 will be better.  If it would
be better than even new fortran for numerical work plus decent OOP features
plus garbage collection... Wow!! 

Ppupupupupupppppplease? :-)

Why not try and make it really really excellent before you have the crushing
burden of backwards compatibility?

: David Chase
: Sun

Matt Kennel
mbk@inls1.ucsd.edu


======================================================================== 50 ===
Date:    13 Mar 92 23:41:43 GMT
From:    chased@rbbb.Eng.Sun.COM (David Chase)
Subject: Re: Modula-3 For scientific/mathematical programming ?

In article <ks28thINNf1l@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel) 
writes:
>Have you been reading the present thread in comp.lang.misc and
>comp.lang.fortran?

>So, in some sort of vague psuedocode:
>	for i,j: C(i,j) = sum k : A(i,k) * B(j,k)
>Which says C = A * Transpose(B) in a straightforward way, of course, assuming
>it can figure out the array bounds for i,j,k, which is often not much
>a problem.  (And the "sum" is an expression, not part of a statement).

>Why not try and make it really really excellent before you have the crushing
>burden of backwards compatibility?

There's a couple of things to note -- first, I'm a member of the
peanut gallery, not the committee proper (though people on the
committee read this stuff).  I had some influence on the original
language, but I was hardly one of its definers.

Second, there is a definite "Modula tradition" that is followed in the
language.  I don't know if this is a bug or a feature; it seems to
depend on what one is familiar with.  You'd have to make an effort to
get your syntax into the "Modula tradition", just for starters.  (I'll
have a shot at it, below.)

Third problem is that "really really excellent" is very subjective.
Given the C++ experience, it looks a policy of "just say 'no' to nifty
new features" is probably a wise one.  Also, the net is not someplace
that I'd for for deep thoughts and reasoned argument.

If you were asking me what *I* wanted for *my* programming, as opposed
to what I think would make the language successful, I'd be very
interested in closures.  It is possible to close over both object
methods and over nested functions (in fact, given that traced objects
are managed by the garbage collector, method closures are a
no-brainer).  I'd also lobby hard for anonymous functions (lambda
expressions, more or less).  I thought for a moment about automatic
coercion of expressions to lambda expressions, but I think I can
demonstrate why that is not going to fly (see example far below).

Now, about your array syntax.  I think you had two things going on
there -- one was the sum expression, the other was the "forall array
elements i and j".  Offhand, I'd have to admit to a little bit of
queasiness here.  My first try at syntax came out looking sufficiently
like a function that maybe you ought to try writing it that way first:

(Here follows my first use ever of a generic interface:)

  GENERIC INTERFACE G(Result);
  PROCEDURE Sum(from,to,by:INTEGER;
                PROCEDURE Plus(x,y:Result.T):Result.T;
                PROCEDURE Element(i:INTEGER):Result.T) : Result.T;

  END G.

  GENERIC MODULE G(Result);
  PROCEDURE Sum(from,to,by:INTEGER;
                PROCEDURE Plus(x,y:Result.T):Result.T;
                PROCEDURE Element(i:INTEGER):Result.T) : Result.T =

  VAR i:INTEGER;
  VAR accumulator:Result.T := Result.Zero.
  BEGIN
    FOR i := from TO to BY by DO
	accumulator := Plus(accumulator,Element(i));
    END;
  RETURN accumulator;
  END Sum;
  END G.

  INTERFACE Float;
  TYPE T = FLOAT;
  CONST Zero : FLOAT = 0.0;
  PROCEDURE Plus(x,y:T):T;
  END Float;

  INTERFACE Floatsum = G(Float) END Floatsum.
  MODULE Floatsum = G(Float) END Floatsum.

So, in my code I might say:

  VAR a : REF ARRAY OF ARRAY OF FLOAT;
  VAR j:INTEGER;
  PROCEDURE Bogus(INTEGER i) : FLOAT = BEGIN RETURN a[i,j]; END;
  ...
  x := Floatsum.Sum(1,n,1,Float.Plus,Bogus);

Of course, if we had lambda expressions (I'll use constructor syntax
with a procedure type):

  VAR a : REF ARRAY OF FLOAT;
  VAR j:INTEGER;
  ...
  x := Floatsum.Sum(1,n,1,Float.Plus,PROCEDURE(i:INTEGER):FLOAT{a[i,j]});

Now, if we had automatic coercion of expressions into functions, we
might try writing:

  VAR a : REF ARRAY OF FLOAT;
  VAR j:INTEGER;
  ...
  x := Floatsum.Sum(1,n,1,Float.Plus,a[i,j]);

This works, just this once, because we can see that we have an
expression with one unbound integer (i) that could yield a float, in a
context where a procedure from an integer to a float is called for.
Thus, there is exactly one way to "Do What I Mean".  Suppose I had
instead written:

  VAR a : REF ARRAY OF FLOAT;
  VAR i,j:INTEGER;  (*  <----- Note the declaration of i *)
  ...
  x := Floatsum.Sum(1,n,1,Float.Plus,a[i,j]);

Now there's no unbound integer -- what do I mean in this case?

So, the situation is not perfect, but it isn't as horrible as you
might have thought.  Presumably (if you think this is important) you
could look into defining a standard library of these combining
functions.  They could be inlined, of course.

Of course, the syntax for defining "temporary" procedures is pretty
horrid.  It's that good old Modula tradition again.  It would be far
nicer if we could have a ton of optional syntax -- for example, in the
above, if we could say

  x := Floatsum.Sum(1,n,1,Float.Plus,PROCEDURE(i){a[i,j]});

and rely on the type checker to infer that in fact, i is an integer,
and the result type is a float.  But, (to debate with myself) what
about procedures that return nothing?  We have no syntax for them.
Grumble, grumble.  I think I'd wave my arms at this point (if I were
on the committee) and say "shorthand, shorthand".  After all, that's
really what you wanted, isn't it?  It's kind of a shame that PROCEDURE
has so many letters in it.

Well, I'm all tuckered out now, and I didn't even get to the
elementwise array assignment.  I hope this was enlightening on more
than one level -- here's one way to do what you want in M3, here's
another person's view on what is "really really excellent" (and it
isn't the same as your view), and here's an example of how things
don't always turn out as planned (in tis case, anonymous lambda
expressions).

David Chase
Sun


======================================================================== 51 ===
Date:    13 Mar 92 20:54:39 GMT
From:    do12+@andrew.cmu.edu (Dick Orgass)
Subject: Re: Windows development under Mod3?

It may actually be possible to bring up Modula-3 on DOS 5 for 386 and
higher machines.

There's a DOS 32-bit port of gcc and g++ together with what appears to
be an adequate but not great library.  The compiler actually uses ld,
ar, as, etc from GNU and ld produces an a.out file.  There's a stub
program that converts the a.out into a .exe.

This might well be enough to bring up the compiler, driver and large
parts of the library.  My guess is that the big question is using
setjmp/longjmp to implement threads.

The compiler itself is supposed to have been compiled by gcc in the
usual way and seems to run well on a 16 Mhz machine with 10Meg.  I
haven't done enough with it to have more of an opinion.

The compiler itself can be found in directory /pub/msdos/djgpp on
grape.ecs.clarkson.edu [128.153.28.12].

Dick


======================================================================== 52 ===
Date:    14 Mar 92 00:15:02 GMT
From:    mbk@lyapunov.ucsd.edu (Matt Kennel)
Subject: Re: Modula-3 For scientific/mathematical programming ?

goldberg@parc.xerox.com (David Goldberg) writes:
: Yes, I have looked at using Modula-3 for scientific programming. 
: Overall, it is my (highly biased) opinion that Modula-3 is almost as
: good as FORTRAN for scientific computing.
: 
: First of all, there are the general plusses of Modula-3: strong typing,
: interfaces, etc.
: 

Fine, but many languages have those.

: For mathematical uses, some of the advantages are (1) generics, so that
: you can generate the single and double precision versions of programs
: automatically, (2) three float-types, so that you can access extended
: precision (on machines which have it) in a portable way, (3) good
: control over floating-point arithmetic.  There are built-in
: floating-point interfaces which let you easily get the values of machine
: epsilon, smallest representable number, etc.;  a standard (i.e. required
: interface) way to access IEEE arithmetic (such as rounding modes) on
: machines that have it, ability to query the type of arithmetic being
: used, and the ability to query (and manipulate) how a machine handles
: exceptions like overflow.  Thus programs can deal with rounding,
: overflows, and underflows in a portable way (portable across machines
: that implement Modula-3, that is).

Those are small details from my point of view.

: 
: The disadvantages are much like C, Pascal, etc:  (1) no built-in complex
: type, (2) no built-in exponential function

These are big omissions, though.

: (3) arrays don't match
: FORTRAN (they are zero-based and stored by row, not column)

No big deal.

: (4) there
: isn't a standard required math library for transcendentals

A Big deal.	:-(

: (5) no simple
: way to specify floating-point constants exactly (i.e. in binary).

A little deal.

: However, unlike C and Pascal, Modula-3 does handle functions that take
: arbitrary-length arrays as arguments:  the size of an array argument can
: be instantiated at call-time.

Non crippled.  Good.

I have the feeling that computer scientists have an odd idea of what
is really important for scentific programming:  according to their
language decisions(actions not words), it's critical to get floating
point interfaces for "machine epsilon", a standard way of getting
at those damn IEEE "rounding modes", and manipulate how to handle
"overflow",  and yet, no complex numbers, few standard mathematical functions,
no exponentiation, no *good* array support.  Great on the details and
lousy on the big picture.

So raise you hand if you want Modula-4 or Oberon-3...

: 	David Goldberg
: 	goldberg@parc.xerox.com


======================================================================== 53 ===
Date:    Fri, 13 Mar 92 21:01:17 PST
From:    <stolfi@src.dec.com>
Subject: Re: Modula-3, Fortran, Numbers & Aliens


    > [Matt Kennel:] So here's the problem:  Write a program to do...
    >
    > for i,j: C(i,j) = sum k : A(i,k) * B(j,k)
    >
    > Which says C = A * Transpose(B) in a straightforward way, of course,
    > assuming it can figure out the array bounds for i,j,k, which is
    > often not much a problem.  (And the "sum" is an expression, not
    > part of a statement).
    > 
    > [...]
    > 
    > Sheesh.  I think i'll stick with
    >     DO I=1,N
    >       DO J=1,N
    >       SUM = 0.0
    >       DO K=1,N
    >       SUM = SUM + B(I,K) * C(J,K)
    >       ENDDO
    >       A(I,J) = AUM
    >       ENDDO
    >     ENDDO

Well, don't let David's elucubrations scare you too much.
In Modula 3 you CAN use meat-and-potatoes FOR loops:

  FOR i := 1 TO N DO
    FOR j := 1 TO N DO
      VAR sum: REAL := 0.0;
      BEGIN
        FOR k := 1 TO N DO
          sum := sum + B[i,k] * C[j,k]
        END;
        A[i,j] := sum
      END
    END
  END

Or, also,

  FOR i := 1 TO N DO
    WITH ai = A[i], bi = B[i] DO
      FOR j := 1 TO N DO
        WITH cj = C[j] DO
          VAR sum: REAL := 0.0;
          BEGIN
            FOR k := 1 TO N DO sum := sum + bi[k] * cj[k] END;
            ai[j] := sum
          END
        END
      END
    END
  END

But I would probably write

  PROCEDURE Dot(VAR x, y: ARRAY OF REAL): REAL =
    VAR sum: REAL := 0.0;
    BEGIN
      FOR k := FIRST(x) TO LAST(x) DO
        sum := sum + x[k] * y[k]
      END;
      RETURN sum
    END Dot;

  FOR i := 1 TO N DO
    FOR j := 1 TO N DO
      A[i,j] := Dot(B[i], C[j])
    END
  END;

I suppose these bits of code will not convince you to give up fortran,
but hopefully they will reassure you that we "CS types" are not
entirely out of our minds (yet).

  Jorge Stolfi
  Modula-3 User
  DEC SRC



======================================================================== 54 ===
Date:    14 Mar 92 01:07:16 GMT
From:    mbk@lyapunov.ucsd.edu (Matt Kennel)
Subject: Modula-3, Fortran, Numbers & Aliens



	So here's the problem:  Write a program to do...

: >	for i,j: C(i,j) = sum k : A(i,k) * B(j,k)
: >Which says C = A * Transpose(B) in a straightforward way, of course, assumin
g
: >it can figure out the array bounds for i,j,k, which is often not much
: >a problem.  (And the "sum" is an expression, not part of a statement).


	David's Modula-3 solution(?)...

chased@rbbb.Eng.Sun.COM (David Chase) writes:
:   GENERIC INTERFACE G(Result);
:   PROCEDURE Sum(from,to,by:INTEGER;
:                 PROCEDURE Plus(x,y:Result.T):Result.T;
:                 PROCEDURE Element(i:INTEGER):Result.T) : Result.T;
: 
:   END G.
: 
:   GENERIC MODULE G(Result);
:   PROCEDURE Sum(from,to,by:INTEGER;
:                 PROCEDURE Plus(x,y:Result.T):Result.T;
:                 PROCEDURE Element(i:INTEGER):Result.T) : Result.T =
: 
:   VAR i:INTEGER;
:   VAR accumulator:Result.T := Result.Zero.
:   BEGIN
:     FOR i := from TO to BY by DO
: 	accumulator := Plus(accumulator,Element(i));
:     END;
:   RETURN accumulator;
:   END Sum;
:   END G.
: 
:   INTERFACE Float;
:   TYPE T = FLOAT;
:   CONST Zero : FLOAT = 0.0;
:   PROCEDURE Plus(x,y:T):T;
:   END Float;
: 
:   INTERFACE Floatsum = G(Float) END Floatsum.
:   MODULE Floatsum = G(Float) END Floatsum.
: 
: So, in my code I might say:
: 
:   VAR a : REF ARRAY OF ARRAY OF FLOAT;
:   VAR j:INTEGER;
:   PROCEDURE Bogus(INTEGER i) : FLOAT = BEGIN RETURN a[i,j]; END;
:   ...
:   x := Floatsum.Sum(1,n,1,Float.Plus,Bogus);

: 
: Of course, if we had lambda expressions (I'll use constructor syntax
: with a procedure type):
: 
:   VAR a : REF ARRAY OF FLOAT;
:   VAR j:INTEGER;
:   ...
:   x := Floatsum.Sum(1,n,1,Float.Plus,PROCEDURE(i:INTEGER):FLOAT{a[i,j]});
: 
: Now, if we had automatic coercion of expressions into functions, we
: might try writing:
: 
:   VAR a : REF ARRAY OF FLOAT;
:   VAR j:INTEGER;
:   ...
:   x := Floatsum.Sum(1,n,1,Float.Plus,a[i,j]);
: 
: This works, just this once, because we can see that we have an
: expression with one unbound integer (i) that could yield a float, in a
: context where a procedure from an integer to a float is called for.
: Thus, there is exactly one way to "Do What I Mean".  Suppose I had
: instead written:
: 
:   VAR a : REF ARRAY OF FLOAT;
:   VAR i,j:INTEGER;  (*  <----- Note the declaration of i *)
:   ...
:   x := Floatsum.Sum(1,n,1,Float.Plus,a[i,j]);
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Sorry, but "I've Got That Gagging Feeling...."

: 
: Now there's no unbound integer -- what do I mean in this case?
: 
: So, the situation is not perfect, but it isn't as horrible as you
: might have thought.  Presumably (if you think this is important) you
: could look into defining a standard library of these combining
: functions.  They could be inlined, of course.

uhh, I wanted A = B * C^Transpose...... where did that go?  And
for the compiler to figure out loop bounds when it was obvious.

Any anyway, why bother complicating up something that's really simple
and then try to make a really fancy optimizer to undo the damage?
Also your solution still is based on the model of a serial computer,
with the explicit sum and iteration. 

: Well, I'm all tuckered out now, and I didn't even get to the
: elementwise array assignment.


And in the other corner....(better no doubt, but still....)

: In J, you'd write one of:
:         a =. +/  V*W          NB: sum (+/) of product of two arrays.
:or
:         a =. V +/ ..* W       NB: Inner product works fine on vectors.

Well the same to you, you !@#a /2+a XV ..*&!  :-) :-) :-)

Survey says......   BZZZZZZZZZZZZZZZZZZZZTTTT!

Sheesh.  I think i'll stick with
	DO I=1,N
	  DO J=1,N
	  SUM = 0.0
	  DO K=1,N
	   SUM = SUM + B(I,K) * C(J,K)
	  ENDDO
	  A(I,J) = AUM
	  ENDDO
	ENDDO


(I wrote a macro for GNU CC that lets me write SUM(i,1,N, expression),
 so I can do
	for(i=1;i<=N;i++)
	   for(j=1;j<=N;j++)
		A[i][j] = SUM(k,1,B[i][k] * C[j][k]);

	 
No insult intended to you CS folks out there, but it's like talking to aliens.

In other words, Yes I Want A Special Case Syntax I Don't Care If It's
Possible To Do In Some Other Way That's Turing Equivalent Because My Brain
Hurts No I Haven't Taken Graduate CS Courses Sorry I Want To Have A Life.
:-) :-) :-)

Maybe this will convince you...  I want a syntax where the parellelism is
obvious, natural, and semantically close to the way that humans think of
things.  Humans first, computers second.

Humans sometimes have special cases too.  Why is it fine in
every language to write  a = 3*X + sin(4.5), but not the obvious extension
to arrays?

cheers,
Matt
mbk@inls1.ucsd.edu

who was it who said something like, "Mathemeticians are like Frenchmen.
Anything you explain to them they will translate into their own language
whence it becomes totally incomprehensible even to you."

: David Chase
: Sun


======================================================================== 55 ===
Date:    14 Mar 92 02:48:45 GMT
From:    chased@rbbb.Eng.Sun.COM (David Chase)
Subject: Re: Modula-3, Fortran, Numbers & Aliens

In article <ks2ke4INNgui@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel) 
writes:

>No insult intended to you CS folks out there, but it's like talking to aliens.

>In other words, Yes I Want A Special Case Syntax I Don't Care If It's
>Possible To Do In Some Other Way That's Turing Equivalent Because My Brain
>Hurts No I Haven't Taken Graduate CS Courses Sorry I Want To Have A Life.

Actually, I have a pretty nice life.  Don't knock computer science
till you've tried it.

In general, the bulk of the world is completely unable to agree on a
special case syntax -- at a minimum, you have to be able to write down
a specification of what the syntax is and what it means.  It doesn't
matter if I "know what it means", because we haven't yet figured out
how to transfer the contents of my brain into a compiler -- lacking
that, we've got to have a specification.

(  This by the way, is part of the reason why it is interesting to look
   for within-language solutions -- we can at least agree on what it
   means, and then consider shorthand from there.  The use of
   a generic was intended to suggest that (perhaps) one might implement
   it differently -- for expository purposes, I used a simple loop. 
   Obviously, threads are an option, as are weird compiler pragmas to
   enable (in a generic sense) additional parallelizing transformations. )

Anyhow, given that the world does not present a unified request, what
goes in or out of the language is pretty much up to the definers.  In
this case, they relied heavily on precedent.  Modula-2 has been
moderately successful, and its relatives (Cedar Mesa and Modula-2+)
had good and bad features well-known to the people defining Modula-3.
This strategy has a better chance of yielding progress, because much
time is spent correcting old mistakes instead of generating new
mistakes.

( I've been programming in C++ for about 18 months now, and I think it
  is fair to say that I have some experience with "new mistakes".
  The new Cobol standard was so wonderful that I believe an insurance
  company sued (or threatened) the standards committee, Fortran 90
  is Really Really Big, and Common Lisp -- well, I'll bet Common Lisp
  has got what you want, if only you can find it.  On a much smaller
  scale, I once spent a summer tinkering with FP84, and *it* had some
  very interesting "new mistakes".  Language design is hard. )

In the case of Modula-3, the aim (my aim, specifically) was to make it
*possible* to do mathematical programming.  You are correct that
complex should have been added -- it is a small thing (much smaller
than multi-dimensional open arrays, which were added for math. prog.),
and it is very useful.  Standard mathematical functions can be
provided after the fact.  The syntax is, well, Modula.  It says it in
the name.

>Maybe this will convince you...  I want a syntax where the parallelism is
>obvious, natural, and semantically close to the way that humans think of
>things.  Humans first, computers second.

I suppose putting "parallel" in all the procedure names is not what
you had in mind ? (:-) Seriously, you think maybe there's a reason
this problem hasn't been solved?  I've been plenty convinced for
years, but I don't like pounding my head on an insoluble problem when
there's interesting hard problems that I can solve.  I've turned down
jobs to do what you want done because I didn't think I'd be able to
solve the problem (and in fact, the problem remains unsolved, and I
haven't heard much from that company lately).  Good syntax for
parallel semantics appears to be hard.

David Chase
Sun


======================================================================== 56 ===
Date:    14 Mar 92 10:07:33 GMT
From:    qs101@cl.cam.ac.uk (Quentin Stafford-Fraser)
Subject: Re: Modula-3 on HP300 vs HP700


I've been having another goat building 2.03 on my HP9000 300 under HPUX 7.

I did lots of hacks, the main ones being:
1. to use gnumake, 
2. -lBSD added in driver/src/m3makefile and compiler/src/m3makefile
3. INCL changed to INCLDIR after -z4 in driver/src/m3makefile (is this right?)

I also changed the sv_mask from sigset_t to int as mentioned elsewhere.

This got me much further than before, but when I do

>m3make build_libm3 install_libm3

it hangs while compiling LongRealTime.i3. (just seems to loop)

Can anyone help? I'm a bit of a novice at this sort of thing!

 -----------------------------------
 Quentin Stafford-Fraser            
 Cambridge University Computer Lab  
 qs101@cl.cam.ac.uk
 Tel +44 223 334645
 -----------------------------------


======================================================================== 57 ===
Date:    Sat, 14 Mar 92 17:05:53 -0500
From:    Norman Ramsey <nr@Princeton.EDU>
Subject: Re: Modula-3 For scientific/mathematical programming ?

> A few people have been asking for a language that understands essentially
> summation conventions and general index notation, as used in undergraduate
> math.
> 
> So, in some sort of vague psuedocode:
> 
> 	for i,j: C(i,j) = sum k : A(i,k) * B(j,k)
> 
> Which says C = A * Transpose(B) in a straightforward way, of course, assuming
> it can figure out the array bounds for i,j,k, which is often not much
> a problem.  (And the "sum" is an expression, not part of a statement).
> 
> And/or how about a new integer type INDEX, which makes the sums and foralls
> implicit for all repeated indices?

Long ago in a previous life with a startup company, I implemented
implicit summation over repeated indices as part of the ``MATHGRAF
expression language'' that was to be part of some ``lab assistant''
software to run on PC's.  The startup ran out of money long before
MATHGRAF ever got out the door, but I still remember that notation
fondly.  It's concise and elegant, which is probably why physicists
use it in the first place.  It wouldn't surprise me if Macsyma or
Mathematica or one of their ilk provided such a notation.  At any
rate, it's not hard to implement.

Norman Ramsey
nr@princeton.edu



======================================================================== 58 ===
Date:    14 Mar 92 20:43:38 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: Modula-3 book call for errata

Prentice Hall informs me that my book "Modula-3" will soon go into its
second printing. Some people have sent me notes about typos and errors
they've found. If you have found any, this would be a good time to e-mail
them to me.  I will also publish an errata list.

Sam Harbison
Pine Creek Software; Suite 300; 305 South Craig Street; Pittsburgh, PA 15213;
USA. Phone&FAX: +1 412 681 9811. E-mail: harbison@bert.pinecreek.com.


======================================================================== 59 ===
Date:    14 Mar 1992 21:22:43 GMT
From:    mbk@lyapunov.ucsd.edu (Matt Kennel)
Subject: Re: Modula-3, Fortran, Numbers & Aliens

chased@rbbb.Eng.Sun.COM (David Chase) writes:
: In article <ks2ke4INNgui@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel
) writes:
: 
: >No insult intended to you CS folks out there, but it's like talking to alien
s.
: 
: >In other words, Yes I Want A Special Case Syntax I Don't Care If It's
: >Possible To Do In Some Other Way That's Turing Equivalent Because My Brain
: >Hurts No I Haven't Taken Graduate CS Courses Sorry I Want To Have A Life.
: 
: Actually, I have a pretty nice life.  Don't knock computer science
: till you've tried it.

No I have no problem with CS, it's just that I personally don't have
time to learn serious CS in addition to my present degree...

: In general, the bulk of the world is completely unable to agree on a
: special case syntax -- at a minimum, you have to be able to write down
: a specification of what the syntax is and what it means.  It doesn't
: matter if I "know what it means", because we haven't yet figured out
: how to transfer the contents of my brain into a compiler -- lacking
: that, we've got to have a specification.
: 
: (  This by the way, is part of the reason why it is interesting to look
:    for within-language solutions -- we can at least agree on what it
:    means, and then consider shorthand from there.  The use of
:    a generic was intended to suggest that (perhaps) one might implement
:    it differently -- for expository purposes, I used a simple loop. 
:    Obviously, threads are an option, as are weird compiler pragmas to
:    enable (in a generic sense) additional parallelizing transformations. )
: 
: Anyhow, given that the world does not present a unified request, what
: goes in or out of the language is pretty much up to the definers.  In
: this case, they relied heavily on precedent.  Modula-2 has been
: moderately successful, and its relatives (Cedar Mesa and Modula-2+)
: had good and bad features well-known to the people defining Modula-3.
: This strategy has a better chance of yielding progress, because much
: time is spent correcting old mistakes instead of generating new
: mistakes.

Ok, I can agree with this, but..... The concepts of tensor index notation
and complex variables have been around a long long time and are certainly
NOT mistakes.  It's only a question of how to make index notation
usable on a computer.  There's all sorts of research on creating
languages to implement new concepts that are only relevant with a computer--
so why not those other small easy things that are well established outside
computer science?

: 
: ( I've been programming in C++ for about 18 months now, and I think it
:   is fair to say that I have some experience with "new mistakes".
:   The new Cobol standard was so wonderful that I believe an insurance
:   company sued (or threatened) the standards committee, Fortran 90
:   is Really Really Big, and Common Lisp -- well, I'll bet Common Lisp
:   has got what you want, if only you can find it.

Again, tensor notation would make Fortran 90 smaller, or more likely
another langauge as useful as Fortran90 for arrays, but significantly
cleaner and more elegant.

Oh and someone complained about my example:

	for i,j:  A(i,j) = sum k: B(i,k) * C(k,j)

because the sum and whatever isn't easily delimited...

I have no particular attachment to the nitty gritty of the syntax---that's
what CS professionals are useful for.

I don't see anything wrong with

	for i,j : A(i,j) = (sum k B(i,k)*C(k,j))

or whatever....

: In the case of Modula-3, the aim (my aim, specifically) was to make it
: *possible* to do mathematical programming.  You are correct that
: complex should have been added -- it is a small thing (much smaller
: than multi-dimensional open arrays, which were added for math. prog.),
: and it is very useful.  Standard mathematical functions can be
: provided after the fact.  The syntax is, well, Modula.  It says it in
: the name.

Well to be a little unfair, that's like saying C makes it "possible" to do
object oriented programming if you roll your own everything with pointers,
or (stretching things) Fortran can let you write dynamic memory allocators
if you're clever enough with EQUIVALENCE and COMMON blocks.

: >Maybe this will convince you...  I want a syntax where the parallelism is
: >obvious, natural, and semantically close to the way that humans think of
: >things.  Humans first, computers second.


: I suppose putting "parallel" in all the procedure names is not what
: you had in mind ? (:-) Seriously, you think maybe there's a reason
: this problem hasn't been solved?

Oh I agree with you that the general problem is very hard. But can be made
alot easier for some of more common special cases (if numerical mathematics
is just a "special case").  Special Case Customers also spend alot of $$ on
computers, and they generally know standard "science math" but not always
computer science.  The "Grand Challenge" type problems that will require Big
Parallel Uranium (heavier than big iron, ya know) are frequently numerical.
Even in the worst possible world, Microsoft Windows NT-XZ 5.1 shouldn't
require more than a few dozens of processors...

Making parallelization explicit is only a side-benefit for tensor notation.
I was simply thinking of having a language closer to the way users normally
think and write, that can still be precise enough for a computer.

:  I've been plenty convinced for
: years, but I don't like pounding my head on an insoluble problem when
: there's interesting hard problems that I can solve.

I think my particular special case is an interesting easy problem that
a CS grad student or two could solve.  But if you come back and tell
me no, it's actually very difficult to do, and solving would require
P=NP, and the resolution of the Riemann Conjecture, etc. etc. I'd take
your word for it, though I'd still think it was weird.

: David Chase
: Sun

cheers,
Matt Kennel
mbk@inls1.ucsd.edu


======================================================================== 60 ===
Date:    15 Mar 92 04:57:50 GMT
From:    rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell)
Subject: Re: Modula-3, Fortran, Numbers & Aliens

Matt Kennel:
   Humans sometimes have special cases too.  Why is it fine in every
   language to write a = 3*X + sin(4.5), but not the obvious extension
   to arrays?

Huh?  But in j that expression works fine [tests if a is equal to the
expression on the right hand side of the '='] even if X is an array of
arbitrary rank.  ;-)

The problem, as I see it, is not so much getting a language to
recognize your syntax.  It's not even getting a language which will
recognize your semantics.  The problem is convincing people that a
language which has the limitations you envision is worth implementing.

For example, I am now used to treating array indexing as a _function_.
This is significant, because I can use meta-functions and the like to
derive new functions based on array indexing.  You can live with
treating array indexing as an operation with anomalous syntax, but why
should I have to?

[And remember, if you can come up with a useful enough of a reason,
you might even convince me to switch to your style of thinking...]

-- 
Raul Deluth Miller-Rockwell                   <rockwell@socrates.umd.edu>


======================================================================== 61 ===
Date:    15 Mar 92 22:09:33 GMT
From:    lindsay+@cs.cmu.edu (Donald Lindsay)
Subject: Re: Modula-3, Fortran, Numbers & Aliens


In article <9203140501.AA01871@jumbo.pa.dec.com> stolfi (Jorge Stolfi) writes:
>    > for i,j: C(i,j) = sum k : A(i,k) * B(j,k)
>But I would probably write
>
>  PROCEDURE Dot(VAR x, y: ARRAY OF REAL): REAL = 
	...
>  FOR i := 1 TO N DO
>    FOR j := 1 TO N DO
>      A[i,j] := Dot(B[i], C[j])
>    END
>  END;

This treatment seems to have lost the transposition of C.
-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science


======================================================================== 62 ===
Date:    Mon, 16 Mar 92 10:25:18 EST
From:    Mr Richard Thomas <richard@snow.fit.qut.edu.au>
Subject: Re: Modula-3 for scientific/mathematic programming

> : The disadvantages are much like C, Pascal, etc:  (1) no built-in complex
> : type, (2) no built-in exponential function
> 
> These are big omissions, though.

May I ask the math people why these are big omissions?  You can easily
build your own Complex object (that's why objects were invented, to let
you add features to your environment.)  And you can make a generic
exponential function.  Most math people that I have had discussions with
just answer this with, but I want it built-in.  Which is more of "I don't
want to learn something new."  Now, if you want to say that if these aren't
built-in, then we can't optimize them enough to make code useable, now I'll
agree.  (Which is why I didn't argue too much against the addition of a
built-in COMPLEX type in ISO Modula-2 (yes it is there now!))
 
> : (4) there
> : isn't a standard required math library for transcendentals
> 
> A Big deal.	:-(

Now I agree this is a Big Mistake.  IMHO I thought this was the biggest
problem with Modula-2, no standard libraries (and we are not just talking
about math).  And yet everyone who has gone on to extend Modula-2 has
fallen into the same error.  This lack of standard libraries not only
scares off the math people, but also a fair chunk of the CS community as
well.

Au revoir,

@~~Richard Thomas  aka. The AppleByter  --  The Misplaced Canadian~~~~@
{ AARNet: richard@snow.fit.qut.edu.au   InterNet: R.Thomas@qut.edu.au }
{ PSI:    PSI%505272223015::R.Thomas                                  }
@~~School of Computing Science - Queensland University of Technology~~@



======================================================================== 63 ===
Date:    16 Mar 92 05:16:10 GMT
From:    mbk@lyapunov.ucsd.edu (Matt Kennel)
Subject: Re: Modula-3, Fortran, Numbers & Aliens

rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) writes:
: In article <ks2ke4INNgui@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel
) writes:
: >Maybe this will convince you...  I want a syntax where the parellelism is
: >obvious, natural, and semantically close to the way that humans think of
: >things.  Humans first, computers second.

Shoot--I screwed up.  I wanted to add "syntactically similar to the
way humans write things" as well. Sorry.

: 
: OK. How do you tell a child to compute the mean of a set of numbers.
: "Add the numbers, and divide by the number of numbers". (Note that
: we don't have to tell the child how many numbers there are. It's 
: implicit in the data. Same in J and APL. 
: 
: We can do this several ways:
: 
:    (+/ N) % $ N       NB: Add up N ( +/ N) and divide (%) by number of number
s ($ n) 
: <more examples deleted>

: >Humans sometimes have special cases too.  Why is it fine in
: >every language to write  a = 3*X + sin(4.5), but not the obvious extension
: >to arrays?

: 
: Umm, perhaps you are out of date on things. APL has worked this way since
: the late 1960's. Fortran 90 works this way since 1991 or maybe even earlier.

I've *never* thought that no language has ever done this.  My only complaint
is that either the syntax is cumbersome and half kludgey (Fortran 77/90) or
completely different from normal mathematical conventions, and otherwise
very unconventional. (APL)    I think there is a place for conventional
array notation in conventional computer languages to be used by conventional
scientists.  That's all.   There's nothing wrong with APL, but it's just
not the right thing "for the rest of us".

Is it easy to write code to create & search conventional heirarchical trees
in APL?  (I have no idea...)


cheers,
Matt
mbk@inls1.ucsd.edu

: Bob

: Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
: Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
: 18 Fifth Street, Ward's Island
: Toronto, Ontario M5J 2B9 
: Canada


======================================================================== 64 ===
Date:    Mon, 16 Mar 1992 05:52:59 GMT
From:    rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell)
Subject: Re: Modula-3, Fortran, Numbers & Aliens

Matt Kennel:
   Is it easy to write code to create & search conventional
   heirarchical trees in APL?  (I have no idea...)

It is easy with J [which provides boxed arrays, and conditional
execution forms].  It becomes moderately difficult if you are working
with a version of APL which forces you to do some of the storage
management explicitly.

In my opinion, the easiest search algorithm to implement is "breadth
first".

Finally, note that it's possible [even, dare I say it, ...easy] to
traverse a directed graph with cycles in a purely functional manner
(side effect free), with guaranteed termination.

-- 
Raul Deluth Miller-Rockwell                   <rockwell@socrates.umd.edu>


======================================================================== 65 ===
Date:    16 Mar 92 04:51:08 GMT
From:    T.Moore@massey.ac.nz (T. Moore)
Subject: Re: Modula-3 for scientific/mathematic programming

>> : The disadvantages are much like C, Pascal, etc:  (1) no built-in complex
>> : type, (2) no built-in exponential function
>> 
>> These are big omissions, though.
>
>May I ask the math people why these are big omissions?  You can easily
>build your own Complex object (that's why objects were invented, to let
>you add features to your environment.)  And you can make a generic
>exponential function.  Most math people that I have had discussions with
>just answer this with, but I want it built-in.  Which is more of "I don't

Unless you are going to put operators in the language (like in Algol 68)
You have to write
      Multiply(z1, z2);
or    Power(x, n);
I would agree with not having these things built in if operators are
provided. Even so, it is a nuisance having to write code for things
which are so frequently used. The addition of operators, though would
allow standard libraries to take care of the extras.



-- 

Terry Moore <T.Moore@massey.ac.nz>
 Department of Mathematics and Statisics,
 Massey University, Palmerston North, New Zealand

Kronecker: "God made the natural numbers, the rest is the work of man."
Zermelo:   "But I can construct the natural from the empty set alone."
Bystander: "Who said 'You can't get something for nothing.'?"


======================================================================== 66 ===
Date:    Sun, 15 Mar 92 22:16:28 GMT
From:    rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Re: Modula-3, Fortran, Numbers & Aliens

In article <ks2ke4INNgui@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel) 
writes:
>
>
>Maybe this will convince you...  I want a syntax where the parellelism is
>obvious, natural, and semantically close to the way that humans think of
>things.  Humans first, computers second.

OK. How do you tell a child to compute the mean of a set of numbers.
"Add the numbers, and divide by the number of numbers". (Note that
we don't have to tell the child how many numbers there are. It's 
implicit in the data. Same in J and APL. 

We can do this several ways:

   (+/ N) % $ N       NB: Add up N ( +/ N) and divide (%) by number of numbers 
($ n) 

or,    ( +/ %  $ ) N      NB: Use of tacit definition.

or, if you like names:
       sum =.  +/
       dividedby =. %
       sizeof =. $ 
     (sum N) dividedby sizeof N


>
>Humans sometimes have special cases too.  Why is it fine in
>every language to write  a = 3*X + sin(4.5), but not the obvious extension
>to arrays?

Umm, perhaps you are out of date on things. APL has worked this way since
the late 1960's. Fortran 90 works this way since 1991 or maybe even earlier.

Bob






Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada


======================================================================== 67 ===
Date:    16 Mar 92 06:19:19 GMT
From:    gl8f@fermi.clas.Virginia.EDU (Greg Lindahl)
Subject: Re: Modula-3, Fortran, Numbers & Aliens

In article <ROCKWELL.92Mar16005259@socrates.umd.edu> rockwell@socrates.umd.edu 
(Raul Deluth Miller-Rockwell) writes:
>Matt Kennel:
>   Is it easy to write code to create & search conventional
>   heirarchical trees in APL?  (I have no idea...)
>
>It is easy with J [which provides boxed arrays, and conditional
>execution forms].

That's nice; but could you please stop cross-posting this discussion
to the Modula-3 and Fortran groups if it has strayed into the depths
of J, never to return? Edit your newsgroups lines, folks.


======================================================================== 68 ===
Date:    16 Mar 92 18:59:58 GMT
From:    eijkhout@cupid.cs.utk.edu (Victor Eijkhout)
Subject: Re: Modula-3, Fortran, Numbers & Aliens

In article <ks4rl3INNq02@network.ucsd.edu>, mbk@lyapunov.ucsd.edu (Matt Kennel)
 writes:

|> 	for i,j:  A(i,j) = sum k: B(i,k) * C(k,j)

Nice to see how this discussions drifts away from all relevant issues.
I guess Matt has a point of the mind-set of CS'ers.

Parts of what you want already exist in such extensions as Alliant
Fortran: most languages with vector notation (aiming at vector computers)
allow you to write
	sum( B(i,:)*C(:,j) )
which generates a scalar (the inner product of a row of B and a column of C)
and they also allow you to generate vectors:
	A(:,:) = B(:,:)*C(:,:)
by componentwise multiplication, but I've never seen the
combination you want. You could imagine a syntax
	A(:1,:2) = B(:1,:3) * C(:3,:2)
where the compiler matches up :i indexes. Any index not in the left
hand side has to be summed.

Some of the proposed solutions to this problem in previous msgs are
highly objectionable from the point of compiling for parallelism/
vectorization. The more you leave unspecified the better.

If you would write
	for (i,j,k : a(i,j)=a(i,j)+b(i,k)*c(k,j))
and leave it to the compiler to figure out what loop should be
outermost, it would be best by far. Compilers have a hell of a job
figuring out what the user *meant* to say, so that they can rearrange
it for vectorization/ cache reuse/ parallelism.

|> Matt Kennel

Victor.


======================================================================== 69 ===
Date:    Mon, 16 Mar 92 13:22:04 PST
From:    <stolfi@src.dec.com>
Subject: Re: Modula-3, Fortran, Numbers & Aliens


    In article <9203140501.AA01871@jumbo.pa.dec.com> stolfi (Jorge Stolfi) writ
es:
    >    > for i,j: C(i,j) = sum k : A(i,k) * B(j,k)
    > But I would probably write
    >
    >  PROCEDURE Dot(VAR x, y: ARRAY OF REAL): REAL = 
    >  ...
    >  FOR i := 1 TO N DO
    >    FOR j := 1 TO N DO
    >      A[i,j] := Dot(B[i], C[j])
    >    END
    >  END;
    
    This treatment seems to have lost the transposition of C.

Perhaps I am being dense, but I think that what I wrote is indeed is
A := B*TRANSPOSE(C).  Note that C[j] means *row* j of C, not *column* j.

  Jorge Stolfi
  Modula-3 User
  DEC SRC

PS.  Unfortunately I cannot code A := B*C in the same style, because
M3 does not let me select a *column* of a matrix and treat it as as vector.
But FORTRAN has a similar restriction, doesn't it?

PPS.  If I well remember, Algol 68 would let you take arbitrary slices
of arrays.  Not only that, but if X was an array of records, all of
them with a field named "foo", you could write X.foo to get an array
consisting of those fields only (as locations, not just values).

These features are relatively trivial to implement: you only need to
include one extra word in every array descriptor.  As a bonus, you
will get the ability to do general transposition, cropping, reversal,
and subsampling of n-dimensional arrays.  But the Holy Dogma of
Simplicity (known to ecologists as "Breeders' Strategy") says that
languages shall be designed for the benefit of implementors, 
not of users...





======================================================================== 70 ===
Date:    16 Mar 92 19:08:58 GMT
From:    jlg@cochiti.lanl.gov (Jim Giles)
Subject: Re: Modula-3, Fortran, Numbers & Aliens

In article <1992Mar15.221628.24491@yrloc.ipsa.reuter.COM>, rbe@yrloc.ipsa.reute
r.COM (Robert Bernecky) writes:
|> In article <ks2ke4INNgui@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kenne
l) writes:
|> >
|> >
|> >Maybe this will convince you...  I want a syntax where the parellelism is
|> >obvious, natural, and semantically close to the way that humans think of
|> >things.  Humans first, computers second.
|> 
|> OK. How do you tell a child to compute the mean of a set of numbers.
|> "Add the numbers, and divide by the number of numbers". (Note that
|> we don't have to tell the child how many numbers there are. It's 
|> implicit in the data. Same in J and APL. 

I don't understand how this argument is relevant to the discussion.
The J notation you gave is nearly identical to the proposed Fortran
syntax for which Matt Kennel has been arguing.  Your statement supports
rather than refutes him.  His notation would give:

   Ave = (sum i: N(i))/size(N)

Whereas yours gives:
|> 
|>    (+/ N) % $ N       NB: Add up N ( +/ N) and divide (%) by number of numbe
rs ($ n) 

Or worse.  Frankly, I think the first would be easier to explain to 
a child (or anyone else).

J. Giles


======================================================================== 71 ===
Date:    Mon, 16 Mar 92 16:43:45 GMT
From:    adam@visix.com
Subject: Re: Modula-3, Fortran, Numbers & Aliens


Do I sense another Herman Rubin in the making :-) :-) :-)

Yes, I know, computer scientists have a way of making things
too complicated.

But essentially you're saying, "all I want is a Do What I Mean
instruction".

Perhaps we don't understand your requirements.

But perhaps you don't understand our constraints.

Adam

"If you want a job done right, you have to do it yourself."


======================================================================== 72 ===
Date:    16 Mar 92 16:44:55 GMT
From:    dagenais@vlsi.polymtl.ca (Michel Dagenais)
Subject: Remote Method call (or OO RPC)

Is anything getting done for Modula 3 in this area. I vaguely remember
someone at Xerox Parc generating stubs for RPC. I would like to have
persistent objects (Modula 3 objects pickled to disk for now) accessible
from any number of viewers (or clients) through OO RPC. Some kind of daemon
would locate a desired object for a client (directory service), start a
process to serve it and offer various possible interfaces to access
remotely this object (arrays of remote callable methods that depend on the
access rights granted). Of course this is very similar to what the Object
Management Group is doing, but not necessarily benefiting from the Modula 3
flavor (messages through pickles, structural type equivalence).

That brings up an important question: in their current implementation, are
Pickles machine independant to a certain point (byte order, member offset,
word length)?
--
---------------------------------------------------------------------

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

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


======================================================================== 73 ===
Date:    Tue, 17 Mar 92 13:57:34 EST
From:    Mr Richard Thomas <richard@snow.fit.qut.edu.au>
Subject: RE: Modula-3 for scientific/mathematic programming

> Unless you are going to put operators in the language (like in Algol 68)
> You have to write
>       Multiply(z1, z2);
> or    Power(x, n);
> I would agree with not having these things built in if operators are
> provided. Even so, it is a nuisance having to write code for things

Good point.  I had thought of this before, but forgot to mention it
in my post.  Who else out there wants to see operator overloading in
Modula-3?  Not only does it solve some of the problem with this 
example, but it provides a very flexible tool for library code.

Au revoir,

@~~Richard Thomas  aka. The AppleByter  --  The Misplaced Canadian~~~~@
{ AARNet: richard@snow.fit.qut.edu.au   InterNet: R.Thomas@qut.edu.au }
{ PSI:    PSI%505272223015::R.Thomas                                  }
@~~School of Computing Science - Queensland University of Technology~~@



======================================================================== 74 ===
Date:    16 Mar 92 15:09:55 GMT
From:    dagenais@vlsi.polymtl.ca (Michel Dagenais)
Subject: PostScript out of Trestle

Trestle comes with X11 support. An object receives paint commands from a
VBT tree and translates them to X11 drawing operations. To get PostScript
output i presume that a similar object would need to translate the paint
commands into PostScript commands. Of course this assumes that similar
fonts are available and so on...

Does such a thing already exists?

By the way, we are still in the process of trying Trestle on small toy
applications but so far so good, we like it a lot!
--
---------------------------------------------------------------------

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

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


======================================================================== 75 ===
Date:    Mon, 16 Mar 92 19:35:37 GMT
From:    adam@visix.com
Subject: Re: Modula-3, Fortran, Numbers & Aliens

In article <ks4rl3INNq02@network.ucsd.edu>, mbk@lyapunov.ucsd.edu (Matt Kennel)
 writes:

|> I have no particular attachment to the nitty gritty of the syntax---that's
|> what CS professionals are useful for.

You better SMILE when you say that, pardner ...

Adam

:-)


======================================================================== 76 ===
Date:    17 Mar 92 05:17:14 GMT
From:    n8243274@henson.cc.wwu.edu (steven l. odegard)
Subject: Re: Modula-3 for scientific/mathematic programming

richard@snow.fit.qut.edu.au (Mr Richard Thomas) writes:
>Who else out there wants to see operator overloading in Modula-3?

I feel that this overloading should be property of a combination of
object-oriented interfaces and pre-processor that parses into Modula-3.

	Parse( Matrix, "M * A + M * B" )
would expand into
	Matrix.Add( Matrix.Mult( M, A ), Matrix.Mult( M, B ) ) ;
or use temporarily-declared variables if the expanded expression would
be too complicated for the compiler to parse.

Such a project could also provide exponentiation.
	CONST E = ComplexLongreal.T{ Re := Math.exp( 1.0d0 ), Im := 0.0d0 }" ;
	VAR A, B := ComplexLongreal.T{ Re := 1.0d0, Im := 0.0d0 } ;
	  X := Parse( ComplexLongreal, "A + B*E**T{1,1}" ) ;

I would like to see a TYPE BCD in the SYSTEM interface, to add support for
all of the processors that include BCD instructions [most of them].

Speaking of which, I envision Modula-3 as the best potential Business-oriented
language.  The pkl interface has potential for database applications. 
--SLO


======================================================================== 77 ===
Date:    Tue, 17 Mar 92 12:20:24 -0500
From:    Norman Ramsey <nr@Princeton.EDU>
Subject: Is Trestle Portable?

Michel Dagenais asked about getting PostScript out of Trestle.  I have
a more general question: how portable is Trestle?  If I want to make
Trestle work on Irises, or a NeXT, using the vendor's graphics
primitives, how much work am I letting myself in for?  What parts of
the Trestle implementation should I look at to learn the answers to
these questions?

Norman Ramsey
nr@princeton.edu



======================================================================== 78 ===
Date:    Tue, 17 Mar 92 06:56:10 PST
From:    msm@.dec.com (Mark S. Manasse)
Subject: Re: PostScript out of Trestle


No, we haven't done any implementations of screen types other than those
for X and for a native Trestle server.  Some interesting classes, besides
PostScript, would be implementations for some version of Windows, for
the Mac, and for 8 1/2.  For PostScript, the main problem is that you
would have to choose a convention for knowing where to insert "showpage";
you could add an extension command to the painting set to indicate it, or
you could wait until the window deleted itself if you just want to capture
a single page.  One other difference is that while painting in response
to user events occurs in sequence, asynchronous painting into different VBTs
is unserialized, unless you explicitly serialize it by using VBT.Sync.  So,
if you have any asynchronous painting you would need to sync all of the VBTs
that had asynchronously painted before declaring yourself done with the
page.

In order to implement a new class of display service, all you need to do is
to implement something parallel to ui/src/xvbtm3, and import it in the
implementation of Trestle (to force it to be linked in).  Sadly, the
interfaces involved aren't quite as well documented as the ones in the
reference manual -- you'll probably want to use the X code as a template.

Mark


======================================================================== 79 ===
Date:    Tue, 17 Mar 92 16:55:22 GMT
From:    rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Re: Modula-3, Fortran, Numbers & Aliens

In article <ks8boqINN8ht@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel) 
writes:
>scientists.  That's all.   There's nothing wrong with APL, but it's just
>not the right thing "for the rest of us".

The difference between APL and mathematical notation is that APL is well-define
d and consistent. Math notation isn't. If it was, math books would be a lot
shorter, because they wouldn't have to spent half their time saying:
 " I use the blech to denote the alternating logarithm of..."

Math has sigma and PI notation for the insertion of an unspecified
function (+ or *) between array items. This is inconsistent and limiting.
APL allows you to specify the function explicitly, thereby offering
more conceptual power (only 1 thing to learn instead of two in this case),
AND being consistent (What you learned about + and * apply consistently to
insert, whereas you have to be told that + and * are related to sigma and
pi): 

sigma =. +/
pi =.    */
altsum =. -/
parity =. =/
any    =. +./     NB: +. is "or"
all    =. *./     NB: *.  is "and" 

So, you DO have to learn something new, but it offers the benefits of
being executable, which math is not.

>
>Is it easy to write code to create & search conventional heirarchical trees
>in APL?  (I have no idea...)

APL offers several ways to do this. One way is to use recursive data 
structures. In J, you can create a tree with 3 leaves this way:
    t =.   (2 3$ 8) ;  'hiya folks'  ;   + ` * 

This consists of:
    A table of two rows and 3 columns consisting of 8's.      
    A character list: "hiya folks"
    A two-element "gerund" consisting of the functions + and *.

Now, I can make another array from t, and thereby form arbitrarily
nested objects of any form. Then you use the usual recursive 
techniques (or others, if you prefer) to traverse them.

Bob




Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada


======================================================================== 80 ===
Date:    18 Mar 92 01:13:20 GMT
From:    chased@rbbb.Eng.Sun.COM (David Chase)
Subject: Re: Modula-3, Fortran, Numbers & Aliens

In article <9203162122.AA04024@jumbo.pa.dec.com> stolfi (Jorge Stolfi) writes:
>PS.  Unfortunately I cannot code A := B*C in the same style, because
>M3 does not let me select a *column* of a matrix and treat it as as vector.
>But FORTRAN has a similar restriction, doesn't it?
>
>PPS.  If I well remember, Algol 68 would let you take arbitrary slices
>of arrays.  Not only that, but if X was an array of records, all of
>them with a field named "foo", you could write X.foo to get an array
>consisting of those fields only (as locations, not just values).
>
>These features are relatively trivial to implement: you only need to
>include one extra word in every array descriptor.  As a bonus, you
>will get the ability to do general transposition, cropping, reversal,
>and subsampling of n-dimensional arrays.  But the Holy Dogma of
>Simplicity (known to ecologists as "Breeders' Strategy") says that
>languages shall be designed for the benefit of implementors, 
>not of users...

Careful there -- at least one implementor was willing to sign on for
somewhat more general arrays that we got.  There's at least 3
different levels of support for arrays that (easily) be imagined:

1. (what we've got) top-level subarrays only -- no support for
   sectioning a matrix into pieces.  This requires that a descriptor
   provide (at minimum) the address of the array and the size of
   each dimension.

   Two particular benefits are:

   a) don't need to invent new SUBARRAY syntax.
   b) indexing in the trailing dimension is guaranteed to be
      unit-stride.

2. (what I wish we had) generally N-dimensional SUBARAY.  Given
   a [0..M, 0..N] matrix, I can partition it into whatever
   2-dimensional index-contiguous pieces I choose.

   This requires that the descriptor also contain the row-to-row
   stride, as well as the length of a row.

   Two particular benefits are:

   a) Much easier to do interesting matrix manipulations
      in recursive programs, since subdivision is a cinch.
   b) indexing in the trailing dimension is guaranteed to be
      unit-stride.

   I would have been perfectly happy with additional parameters to
   SUBARRAY, along the lines of:

   WITH UL = SUBARRAY(A,0,M/2,0,N/2),
        UR = SUBARRAY(A,0,M/2,N/2+1,N),
        LL = SUBARRAY(A,M/2+1,M,0,N/2),
        LR = SUBARRAY(A,M/2+1,M,N/2+1,N) DO ... END

3. (what I contemplated) General index-to-index affine
   transformations.  Given an array A with D dimensions,
   I can construct an alias A' with D' dimensions.  This requires (in
   the descriptor) information about the element to element stride
   in the trailing dimension.  A sick person might choose to overload
   this onto the WITH statement (strap on your barf bags, examples
   follow):

   WITH A[i,j] = B[j,i] DO
     ...
   END

   WITH ROWi[j] = B[i,j] DO
     ...
   END

   WITH COLj[i] = B[i,j] DO
     ...
   END

   WITH D[i] = B[i,i] DO
     ...
   END

   WITH UpperD[i] = B[i,i+1] DO
     ...
   END

   This has the disadvantage of not limiting the indices in any
   explicit way, but this is just an exercise.  Also, this is a very
   general general case -- it could slow down some (naively compiled)
   code in the unextended language.  At some time or
   another, something like this was contemplated for Fortran 90, but I
   don't know offhand if it made it in or not.

Now, it turns out that what was implemented at Olivetti in fact could
have supported option 2 above (for a while, rows of arrays were
allocated in 2-byte boundaries.  This was a Bad Idea).  It certainly
wasn't a killer in terms of implementation cost.

If anyone cares, you'll notice that these are compatible extensions to
Modula-3 -- supporting them does not change the meaning of any legal
program.  There's some question about efficiency problems for other
programs if you support option 3 -- you'd like to at least have a
"decent" compiler that would recognize that the element-to-element
stride was loop invariant, and special cases in a lot of the library
code to spot the unit stride case.

David Chase
Sun


======================================================================== 81 ===
Date:    Wed, 18 Mar 92 14:49:49 CST
From:    sya@prism.keh.utulsa.edu (Syed Shibli)

Please add me to your Modula-3 mailing list.

   sya@prism.keh.utulsa.edu

Thanks,
Syed


======================================================================== 82 ===
Date:    Thu, 19 Mar 1992 15:57:44 GMT
From:    abbas@osf.org (Abbas Birjandi)
Subject: Looking for material on threads


Hi,

I am looking for tutorials, public domain examples, etc for preparing
a one day hands on course on threads.  I would appreciate any pointers, hints
to anything useful that I can use in preparing my lectures and examples.

Thanks.

Abbas


PS:Please respond by mail to abbas@osf.org


======================================================================== 83 ===
Date:    20 Mar 92 02:32:58 GMT
From:    gajarsky@pilot.njin.net (Bob Gajarsky)
Subject: SURVEY:Please read, for scholastic purposes.


	Please note this message is being crossposted to a large number
of groups.  I am sorry for any inconvenience, but there are members of
many newsgroups that I wish to reach , and this is the only way that
I can accomplish this.  Thank you for your understanding.

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

	My name is Bob Gajarsky.  I am a graduate level management student, 
and am conducting a survey for one of my classes.  It would greatly help my 
studies if you could take a few minutes and complete the following survey.  
All results will be kept completely confidential, and your e-mail addresses 
will not be seen by anyone but me.
	
	Also, I am only looking for complete surveys from people who are
actually out in the workplace as computer programmers, as opposed to those 
(like me) who are students.  Additionally, I would request that only people 
who work in the United States reply to this.  Thank you in advance for your 
responses.

--------------------------- BEGINNING OF SURVEY -----------------------------

What city is your place of work?	-
(OPTIONAL) What company do you work at?	-

How many years of programming experience do you have?

How many years of post-high school education have you had?
	
How many computer languages do you know?
	If you program in any of the following languages, please check it:

	Ada		APL		Cobol
	C		C++		Fortran
	Lisp		Pascal

How many software packages do you know how to use (ie. Lotus, MS-Works, etc.)

	1-2		3-5		6-8
	9-10		over 10

Do you know any databases? (Y/N)
	If so, which ones?

On the average, how many hours does it take you to learn a application (ie. 
	Word Processor, Graphics Package, etc.)?
	
How do you prefer to learn new applications?  More than one may be checked:
	Tutorials
	Videos
	Self-Instruction
	Other  _________________________

Do you personally have a VCR? (Y/N)

Does your workplace have a VCR? (Y/N)

Have you ever used a video to learn an application before? (Y/N)
	If so, how would you rate it?
	(10 is an excellent experience, 1 is an awful experience)
	Based on your past experiences, would you be receptive to learning
		another application via video?
		(10 is very receptive; 1 is not receptive at all)

	If not, how receptive would you be to learning a application via video?
		(10 is very receptive; 1 is not receptive at all)

How many hours of video would you be able to successfully watch for
	a specific application?

How much would you or your company pay for the following:
	A) A 15 hour video that teaches how to generally work with databases,
		program in them, and utilize them.  (Between 40$ and 150$)
	B) A 3 hour video that teaches a specific database, (Oracle, etc.)
		(Between 15$ and 75$).
	C) A packaged of both (A) and (B).
		(Between 50$ and 225$).

Which systems do you have a familiarity with?
	VAX/VMS		UNIX
	Macintosh	IBM Compatible
	Other

-------------------   END OF SURVEY ---------------------------------

Thanks! - Bob Gajarsky


======================================================================== 84 ===
Date:    Fri, 20 Mar 92 10:47:10 GMT
From:    diamond@jit345.bad.jit.dec.com (Norman Diamond)
Subject: Re: Modula-3 For scientific/mathematical programming ?

Having seen the article on this topic that was cross-posted in comp.lang.misc,
I wish to correct some errors.

In article <ks2hc6INNgh0@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel) 
writes:
>goldberg@parc.xerox.com (David Goldberg) writes:
>: The disadvantages are much like C, Pascal, etc:  (1) no built-in complex
>: type, (2) no built-in exponential function
>: (3) arrays don't match
>: FORTRAN (they are zero-based and stored by row, not column)
>: (4) there
>: isn't a standard required math library for transcendentals

Pascal has not suffered the above disadvantages since 1989.
It does seem, however, to suffer a shortage of implementations due to
prejudice in the marketplace.

>: (5) no simple
>: way to specify floating-point constants exactly (i.e. in binary).

Yes, Pascal still suffers that disadvantage.

>A little deal.

>: However, unlike C and Pascal, Modula-3 does handle functions that take
>: arbitrary-length arrays as arguments:  the size of an array argument can
>: be instantiated at call-time.

That is like Pascal, since 1989.

>I have the feeling that computer scientists have an odd idea of what
>is really important for scentific programming:  according to their
>language decisions(actions not words), it's critical to get floating
>point interfaces for "machine epsilon", a standard way of getting
>at those damn IEEE "rounding modes", and manipulate how to handle
>"overflow",

Most languages started without these features, but added them because of
demand from numerical analysts.

>and yet, no complex numbers, few standard mathematical functions,
>no exponentiation, no *good* array support.  Great on the details and
>lousy on the big picture.

Some languages have added these as well.  Some added these at the same
time when other languages were adding the more primitive set of features.
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"Yeah -- bad wiring.  That was probably it.  Very bad."


======================================================================== 85 ===
Date:    Fri, 20 Mar 92 15:53:33 PST
From:    muller@src.dec.com (Eric Muller)
Subject: SRC Modula-3 2.04 available from gatekeeper.dec.com

in pub/DEC/Modula-3/release (note the change of location).


Here are some of the user-visible changes:

- M3makefile's that build libraries must name all of the libraries that
  they import.  This way you'll always get consistent recompilation.

- Warnings are generated for unused imports.

- Runtime error messages include more information about the location of the
  error (e.g. file and line number or PC).

- The runtime supports a simple overlay mechanism that allows us to
  build a "partial link" model of program development.  See the m3 and
  m3make man pages.

- Single stepping into a TRY statment with your debugger should now show
  the "TRY" lines instead of the "EXCEPT" and "FINALLY" lines.

- The explicit checking for NIL Text.Ts was removed.  If you pass NIL
  to one of the Text procedures, you'll get the standard "possible NIL
  dereference" crash.

- RTArgs exports "argc" and "argv", the old values in M3toC are
  marked obsolete. There's a new interface Params that provides
  simple, safe access to the command line arguments without the
  overhead of ParseParams.

- Wr.PutString takes a READONLY array of characters.  The array used to
  be passed by value.

- "FROM X IMPORT y" doesn't import the revelations from X.

- showheap now runs in a different address space than the program under
  investigation (it is now similar to showthread).  This means that
  there is nothing special to do when building a program to use
  showthread; just pass @M3showthread as an argument when running the 
  program.

- recordheap and replayheap to take a closer look at the heap activity.
  As before, the user interfaces are very poor; I am waiting for the 
  availability of FormsVBT to redo them. 

Installation changes:

- The default M3OPT to use in m3makefile is now part of the config
  rather than part of the toplevel template.  There is also a 
  BOOTOPT option in the config, passed to the C compiler when
  compiling the bootstrap C code for the compiler and the driver.

- The m3make component works more like the other components: the derived
  files are created in a separate directory for each architecture.

- INSTALL in the config is now a macro with arguments that expands to
  the full command to use for installing a file.  Together with the 
  previous change, this should allow to install files by creating
  links rather than copying the bits.
 
Some news about the various ports:

- The FloatMode interface has been implemented for SPARC and DS3100.  The
  status is global (not yet per-thread).

- There is a NEXT version for NeXT machine.  This is only a test 
  version.  It incorporates changes to the U* interfaces for 
  NeXT, as reported by Gary Frederick (thanks a lot).

- All HP300 fixes reported by Piet van Oostrum have been incorporated.

Internal changes and bug fixes:

- Debugging symbols for Modula-3 types are generated on a per-library basis.

- Thread stack overflows are detected with write protected "guard pages"
  rather than explicit checking on procedure entry.  The result is
  less code and a more efficient procedure call.  This is used for
  DS3100, VAX and SPARC only.  For the other machines, we need to know
  if mmap() exists and how it works (arguments, returns values).

- Better code is generated for exception handlers and return statements.

- The compiler no longer uses "alloca".

- Subtype tests are compiled in-line.

- Taking the address (explicitly or when passing by VAR) of a VALUE REAL
  parameter works.

- Raising an exception with a one-word argument doesn't require an allocation.

- Generics with no parameters are allowed.

- The builtin operations that take types as arguments correctly declare
  the type. (e.g. LOOPHOLE (a, UNTRACED REF INTEGER) will work even if this
  is the only reference to UNTRACED REF INTEGER.)

- LOOPHOLE (x, ARRAY OF T) works.

- Nested procedures within a module's main body get legal C names.

- "NEW (T, f := P())" doesn't allocate two T's.

- The <*OBSOLETE*> pragma works again.

- RETURN from within a TRY-EXCEPT-ELSE doesn't clobber the pending
  return value.

- Typecell pointers are allocated in each library so shared libraries
  will work on SunOS and OSF.  We haven't yet modified the templates
  to build shared libraries.

- Exceptions with arguments smaller than a word should work.
  This is only a problem on big-endian machines so I can't test my fix.

- The PRAGMA pragma allows you to define pragmas that use Modula-3 reserved
  words.

- The compiler recognizes some (intentionally) undocumented flags that
  disable runtime checks so we can do some performance measurements.

- When a compilation fails, m3 exits with a non-zero status.

- The bogus "unhandled exception" warnings are gone.

- Library names can contain arbitrary characters.

-- 
Eric.



======================================================================== 86 ===
Date:    Fri, 20 Mar 92 15:30:26 PST
From:    muller@src.dec.com (Eric Muller)
Subject: Modula-3 Frequently Asked Questions (FAQ)

Archive-name: Modula-3-faq
Last-modified: Mar 19 1992


			MODULA-3 FAQ
			============


What is Modula-3 ?

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

   Modula-3 descends from Mesa, Modula-2, Cedar, and Modula-2+.  It
   also resembles its cousins Object Pascal, Oberon, and Euclid.

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


Is Modula-3 a superset of Modula-2 ?

   No; valid Modula-2 programs are not valid Modula-3 programs.


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

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

   also known as SPwM3.

   Sam Harbison has written a book about Modula3:

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

   as well as an overview article, "Modula-3", in Byte, Vol. 15,
   Number 12, October 1990, p 385.


Where can I get information on Modula-3 ?

   There is a Usenet newsgroup, comp.lang.modula3.  The archives of
   that group are available via anonymous ftp from gatekeeper.dec.com
   in pub/DEC/Modula-3/comp.lang.modula3.  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.

   Also, Pine Creek Software publishes a free newsletter and various
   announcements about Modula-3 products and activities.  To be added
   to their mailing list, send email or US mail to:

	Pine Creek Software
	Suite 300
	305 South Craig Street
	Pittsburgh, PA 15213
	Phone & Fax: [1] (412) 681 9811
	Email: modula3@bert.pinecreek.com
   

Where can I get an implementation ?

   There is only one implementation available today.  It has been built
   by SRC and is available via anonymous ftp from gatekeeper.dec.com in
   pub/DEC/Modula-3/src-m3.

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

	AIX386	IBM PC running AIX/PS2,
	AP3000	Apollo DN4500 running Domain/OS
	ARM	Acorn R260 running RISC iX 1.21
	DS3100	DECstation 3100 and 5000 running Ultrix 4.0 and 4.2
	HP300	HP 9000/300 running HP-UX 8.0
 	IBMR2	IBM R6000 running AIX 3.1, 
	IBMRT	IBM RT running IBM/4.3, 
	NEXT    NeXT running ?
	SPARC	SPARCstation running SunOS 4.1.x
	SUN3	SUN3 running SunOS
	UMAX    Encore Multimax running UMAX 4.3 (R4.1.1)
	VAX	VAX running Ultrix 3.1

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

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


What if I don't have ftp access ?

   You can contact Pine Creek Software (see the address above).

Can I contribute Modula-3 software ?

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

-- 
Eric.



======================================================================== 87 ===
Date:    Fri, 20 Mar 1992 22:05:51 GMT
From:    ja51359@uxa.cso.uiuc.edu (Jeff Axelrod )
Subject: program to replace keywords by uppercase?

Hi.  Has someone written a program to change all the keywords from lower
to uppercase that they would be willing to mail me?  This would be a great
typing aid.  Thanks in advance!



======================================================================== 88 ===
Date:    Sat, 21 Mar 92 01:03:28 MST
From:    ggf@saifr00.cfsat.honeywell.com (Gary Frederick)
Subject: Re: SRC Modula-3 2.04 available from gatekeeper.dec.com

>There is a NEXT version for NeXT machine.
  That still has a few small problems (-:

I hope to get it up in a few days.  The build went well till
it tried to link and did not find waitpid and mprotect.  It
also had a problem with linking __IS_CLOSURE that I do not
know where it is coming from.  But it looked VERY close.

If you want to try to get it up, this is the version to
build from.  Thanks for the great work.

Gary
ggf@jsoft.com



======================================================================== 89 ===
Date:    Fri, 20 Mar 92 17:23:23 PST
From:    mjordan@src.dec.com (Mick Jordan)
Subject: Re: SRC Modula-3 2.04 available from gatekeeper.dec.com

In article <1992Mar20.155333.21272@src.dec.com>, muller@src.dec.com (Eric Mulle
r) writes:
> in pub/DEC/Modula-3/release (note the change of location).
> 
> 
> Here are some of the user-visible changes:
> 
> - M3makefile's that build libraries must name all of the libraries that
>   they import.  This way you'll always get consistent recompilation.
> 

There is more to it than the above remark suggests and, since I was bitten by i
t, 
I will pass on the warning. In addition the above, all procedures declared in 
interfaces in the library must be implemented by a module in the same library
and all opaque types declared in interfaces in the library must be given
concrete revelations by some interface or module in the same library.

So, you cant structure your system with "abstractions" in one library
and "implementations" in (one or more) other libraries. 

Mick Jordan


======================================================================== 90 ===
Date:    Sat, 21 Mar 92 10:19:29 -0500
From:    Norman Ramsey <nr@Princeton.EDU>
Subject: SRC M3 V2.04

Is version 2.04 considered a beta test version or a reliable version?

Norman Ramsey
nr@princeton.edu


======================================================================== 91 ===
Date:    Sat, 21 Mar 92 14:58:58 PST
From:    gnelson@src.dec.com (Greg Nelson)
Subject: Re: Remote Method call (or OO RPC)

Michel Dagenais asks about the status of object-oriented RPC in Modula-3.

There are several projects for doing RPC in Modula-3, all of which
are using the network object approach, so that an RPC call is made
by invoking the method of an object in another address space.

David Nichols at Xerox PARC has built a stub compiler that takes SUN
RPC interface descriptions and produces a Modula-3 object whose methods
perform the Sun RPC calls.  I understand that he will be releasing
it for public use soon.

David Evers at Cambridge University has done much the same thing for
the ANSA interface description language, which is much used around
Cambridge.

At SRC there is a project underway to build a new RPC system for
Modula-3 based on network objects.  As part of this project, we will
be reimplementing Pickles so that they are independent of byte order,
floating-point format, etc. This is unfortunately not true of the
current implementation.

Greg Nelson




======================================================================== 92 ===
Date:    Fri, 20 Mar 92 15:41:00 GMT
From:    adam@visix.com
Subject: Re: Modula-3, Fortran, Numbers & Aliens


Preclaimer:  I'm feeling a bit peckish today, so I'm going to play
devil's advocate ...

In article <1992Mar17.165522.14818@yrloc.ipsa.reuter.COM>, rbe@yrloc.ipsa.reute
r.COM (Robert Bernecky) writes:

|> Math has sigma and PI notation for the insertion of an unspecified
|> function (+ or *) between array items. This is inconsistent and limiting.
|> APL allows you to specify the function explicitly, thereby offering
|> more conceptual power (only 1 thing to learn instead of two in this case),
|> AND being consistent (What you learned about + and * apply consistently to
|> insert, whereas you have to be told that + and * are related to sigma and
|> pi): 

The problem is that most people already know the two concepts of
sigma and pi notation, so the argument "there are less things to learn"
doesn't fly.  It is perfectly valid for them to say, "I don't have
to learn _anything_ to continue using the notation I have."

To snatch an analogy out of thin air, you lose at Blackjack because
when you bust and the dealer busts, you still pay.

On second thought, forget the analogy.  

The point is, arguments of generality don't cut it with people who
never have to deal with the extra cases.  If all they do is limited
to a particular domain, then all they want is a notation that fits
that domain.

Is that wrong?


Adam


======================================================================== 93 ===
Date:    16 Mar 92 02:42:31 GMT
From:    abbasi@star.enet.dec.com (Nasser ABBASI)
Subject: Re: Modula-3 For scientific/mathematical programming ?


In article <9203142205.AA21344@cs.Princeton.EDU>, nr@Princeton.EDU (Norman Rams
ey) writes...
[..]
>> So, in some sort of vague psuedocode:
>> 	for i,j: C(i,j) = sum k : A(i,k) * B(j,k)
>> Which says C = A * Transpose(B) in a straightforward way, of course, assumin
g

[..]
>Mathematica or one of their ilk provided such a notation.  At any
>rate, it's not hard to implement.
>Norman Ramsey
>nr@princeton.edu


in MATLAB you type

  C= A * B'

and you'r done :-)


/Nasser












======================================================================== 94 ===
Date:    23 Mar 92 14:37:41 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: SIGPLAN Modula-3 BOF

I just looked at the advance program for SIGPLAN '92 in San Francisco,
June 15-19. Many of the tutorial and symposium topics are relevant to
Modula-3, and it appears that our friends from Princeton and U. Mass.
will be giving papers on Modula-3-related topics.

Looks like a good opportunity for a big Modula-3 get-together!
Make your reservations early!

Sam Harbison 
Pine Creek Software; Suite 300; 305 South Craig Street; Pittsburgh, PA 15213;
USA. Phone&FAX: +1 412 681 9811. E-mail: harbison@bert.pinecreek.com.


======================================================================== 95 ===
Date:    Mon, 23 Mar 92 13:04:18 PST
From:    muller@src.dec.com (Eric Muller)
Subject: Re: SRC M3 V2.04

In article <9203211519.AA12563@cs.Princeton.EDU>, Norman Ramsey asks:

> Is version 2.04 considered a beta test version or a reliable version?

I guess this depends on the version.  The DS3100 version is in daily
use at SRC and should be reliable.  The SPARC version is usually very
close to the DS3100 version thanks to the work of PARC.  The other
versions seem to be less used, and suffer from bugs in make, cc, cpp.

As far as we know, all the problems associated with the twelve changes
to the language, or the changes to support "m3 -make"/version stamps
are now solved.  The architecture-independent part is certainly as
reliable as in 1.6, has less bugs and is more efficient.

-- 
Eric.



======================================================================== 96 ===
Date:    Mon, 23 Mar 1992 22:28:08 GMT
From:    jlg@cochiti.lanl.gov (Jim Giles)
Subject: Re: Modula-3, Fortran, Numbers & Aliens

In article <1992Mar20.154100.1603@visix.com>, adam@visix.com writes:
|> [...]
|> The point is, arguments of generality don't cut it with people who
|> never have to deal with the extra cases.  If all they do is limited
|> to a particular domain, then all they want is a notation that fits
|> that domain.

Very good!  I couldn't have said it better myself (if I could, I would
have by now).

The fact is that most numerical/scientific programs don't contain
many reductions other than summation - which they contain lots of.
So, it makes some sense to provide summation in the form that's 
most convenient.  Further, the other reductions that are used, are
so rara (and often used in different contexts entirely), that some
more explicit notation, distinct from summation, might be desireable
just to emphasize the less usual operation.  Note, the most common
reductions other than sum in numerical/scientific programs are min and
max - reductions which have entirely different semantics from sum and
product - so they have to be done differently anyway.

J. Giles


======================================================================== 97 ===
Date:    Mon, 23 Mar 1992 17:18:07 GMT
From:    stenbror@gaya.nki.no ( Stenbro)
Subject: EBNF or YACC Grammar for Modula-3


Hello Modula-3 freaks!!!

I am currently starting a Oberon Compiler prosject for IBM-PC, and i also want 
to write a Modula-3 Compiler for OS/2.
Can anybody mail me EBNF or YACC Grammar of Modula-3 ?????

Thank You!!!





======================================================================== 98 ===
Date:    24 Mar 92 15:28:50 GMT
From:    mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin)
Subject: Re: Modula-3, Fortran, Numbers & Aliens

In article <1992Mar23.222808.6567@newshost.lanl.gov> jlg@cochiti.lanl.gov (Jim 
Giles) writes:

> The fact is that most numerical/scientific programs don't contain
> many reductions other than summation - which they contain lots of.
> So, it makes some sense to provide summation in the form that's 
> most convenient.  Further, the other reductions that are used, are
> so rara (and often used in different contexts entirely), that some
> more explicit notation, distinct from summation, might be desireable
> just to emphasize the less usual operation.  Note, the most common
> reductions other than sum in numerical/scientific programs are min and
> max - reductions which have entirely different semantics from sum and
> product - so they have to be done differently anyway.

I think we ought to be a little careful of this argument.  People tend
to use what is available---what is in their standard vocabulary.  In
mathematics, sum and product have well-known symbols, so people use
them.  Other reductions don't, so people aren't in the habit of using
them.  Users of J have general reductions as part of their normal
vocabulary, so uses for reductions of various kinds are seen
everywhere.  

I once had a teacher that habitually expressed the size of a set as
"the sum, over all elements of the domain, of the indicator function
for the set".  This instead of something simple---|Set|, for example.
Why?  Because he had indicator functions and summation anyway, and it
never occured to him to generalize absolute value to sets.  Another
example: I once had a boss who's pet peeve was recursion.  For him,
the epitome of ivory-tower language design was recursion: it was
simply an unnecessary frill; he had programmed in Fortran for years
and had never needed recursion.  Of course, his code was full of
explicit stacks used to simulate recursion.

This is really a special case of a more general phenomenon.  People
are very conservative.  When they first approach computers, they
automate what they have done by hand for years.  They leave the
process the same, but make it less tedious.  Only much later do they
realize that it is the process itself that needs changing, because the
process was tailored to doing things by hand.  Another example: at a
mine I worked for long ago, the standard way to estimate the amount of
ore available was to hand-construct a Vernoi diagram on a map of drill
holes, use a mechanical planimeter to find the area of each polygon,
estimate the amount of ore within each polygon, and finally add up the
estimates to get the total.  So, of course, the first thing they did
when they bought a computer was to automate this process.  Only
several years later did they realize that simple interpolation between
drill holes is a better ways to estimate the amount of ore; Vernoi
diagrams had been used only because they were easier to do by hand.
(And it turned out that the methods based on interpolation were *much*
easier to program, and ran much faster, than constructing Vernoi
diagrams on the computer.)

So, I'm not saying we shouldn't listen to users.  I'm just pointing
out that users are conservative and often don't know what they need.
Mostly, they will tell you how to make their job less tedious.  They
probably won't tell you that their entire job description ought to
change.  Part of our job is to figure out, from what users *say* they
want, what they *really* need.

-mike


======================================================================== 99 ===
Date:    Tue, 24 Mar 92 06:19:19 GMT
From:    rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Re: Modula-3, Fortran, Numbers & Aliens

In article <1992Mar20.154100.1603@visix.com> adam@visix.com writes:
>
>sigma and pi notation, so the argument "there are less things to learn"
>doesn't fly.  It is perfectly valid for them to say, "I don't have
>to learn _anything_ to continue using the notation I have."
>
>The point is, arguments of generality don't cut it with people who
>never have to deal with the extra cases.  If all they do is limited
>to a particular domain, then all they want is a notation that fits
>that domain.
>
>Is that wrong?

Well, no, it isn't wrong.

BUT, it does mean that they don't tend to think about ideas like:
minimum/maximum of an array; or/and reduce of an array; parity of an
array; minus reduce of an array (done with negative one to the power 
of the (whew) induction variable of the sigma)... as ALL being 
minor variations on the SAME idea:

   "Stick the thing on the left of the slash between the subarrays
    of the right, and evaluate the resulting expression".

So, +/ is sum; */ is product; -/ is negative reduce; or/ is or reduce, etc.

I don't see how sigma and pi notation are easier, except for the 
braindead who are unable to learn anything new. The insert notation
is easier to teach to children(not sure about grad students and doddering
professors) and is consistent, as well as generalizing to ANY function.
I have taught insert notation to children during a 7 minute boat ride,
using nonexistent functions "foo/x". They don't know how to evaluate it,
but they sure know how to convert the expression into one using only foo
and elements of x. 



Mathematicians faced with non-obvious reductions tend to spend a chapter
inventing Another_new_Symbol. Whoopy zing. 


Of course, it took a century or so to get mathematicians to get used to the
idea of using a times sign for multiply, and they still only get it sometimes,
so perhaps I'm being impatient..



Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada


======================================================================= 100 ===
Date:    23 Mar 92 14:48:35 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: Modula-3 shirts

I still have some Modula-3 T-shirts and sweatshirts available.  I have
sweatshirts in sizes L, XL, and XXL (three of each).  I have t-shirts
in sizes L, XL, and XXL (one of each).  First come, first served.

These collector's items are available at cost, plus shipping and handling:

Modula-3 T-shirt, 100% cotton, ash (gray) with maroon Modula-3 logo
  size L or XL      $6.00
  XXL                7.00

Modula-3 Sweatshirt (heavy), ash (gray) with maroon Modula-3 logo
  size L or XL      18.00
  XXL               21.00

Shipping & handling (per sweatshirt, or for up to 3 tees)
  US                 4.00 (priority mail)
  Canada             5.00
  Other              8.00 (surface)

Send a check or money order (US funds, US bank) to:

Pine Creek Software
Suite 300
305 South Craig Street
Pittsburgh, PA 15213-3706
USA


======================================================================= 101 ===
Date:    25 Mar 92 00:42:18 GMT
From:    jlg@cochiti.lanl.gov (Jim Giles)
Subject: Re: Modula-3, Fortran, Numbers & Aliens

In article <MHCOFFIN.92Mar24102850@tolstoy.uwaterloo.ca>, mhcoffin@tolstoy.uwat
erloo.ca (Michael Coffin) writes:
|> [...]
|> I think we ought to be a little careful of this argument.  People tend
|> to use what is available---what is in their standard vocabulary.  In
|> mathematics, sum and product have well-known symbols, so people use
|> them.  Other reductions don't, so people aren't in the habit of using
|> them.  Users of J have general reductions as part of their normal
|> vocabulary, so uses for reductions of various kinds are seen
|> everywhere.  

Scientists and mathematicians have been doing their thing for 
generations.  If there were other reductions widely useful in 
those fields, I suspect they'd have a standardized notation for 
them by now.  Moreso because inventing a syntax to use in textbooks 
and scholarly papers doesn't require any CS type to implement it 
for you.  And, in fact, new notations are invented by every other 
author in these fields - and the best of these notations survive.
I haven't seen any stampeed toward additional reductions though.

The fact is that CS types see all reductions as variations of the
same thing because they aren't in a field in which any of them
dominate over the others.  The assumption that they are actually 
the same and should be supported with the same or similar syntax
is not necessarily true in all application domains.  And if it's
not, using the `generalized' syntax may actually be harmful in
some application domains.  The later seems to be the case (and
I started out supporting an orthogonal syntax like the CS types
are pushing).

|> [... examples of `conservatism' involving Vernoi diagrams and others ...]

The example exhibits marvelously that it's important for programmers
to be aware of a wide variety of algorithms and techniques.  I don't
see that it has much relevance to language design - except to be
a warning not to accept conventional ideas at face value.  That's
why I study the application domain I'm targetting and the programmers
that are involved there.  The conventional idea about reduction, for
example, is that it's notation should be orthogonal for all operators.
I thought so too.  I decided, after studying the issue, that the
conventional wisdom was both right and wrong.  Reduction should be
done orthogonally for all operators in a functional syntax.  In additon,
summation and iteration should be done in a syntax that allows covarying
indices in array expressions to be denoted more clearly and succinctly.

J. Giles


======================================================================= 102 ===
Date:    Wed, 25 Mar 1992 19:03:55 GMT
From:    carter@EuroPARC.Xerox.COM (Kathleen Carter)
Subject: Image object types for Modula-3


I have started using Modula-3 and Trestle and I would like to
manipulate and display raster images grabbed from a video frame
grabber. Has anyone implemented anything that might be useful
for reading raster files in some standard format and for displaying
them in a Trestle VBT?

Thanks.

Kathy Carter



======================================================================= 103 ===
Date:    25 Mar 92 22:46:00 GMT
From:    slagle@lmsc.lockheed.com (Mark Slagle)
Subject: Re: Modula-3, Fortran, Numbers & Aliens

In article <MHCOFFIN.92Mar24102850@tolstoy.uwaterloo.ca> mhcoffin@tolstoy.uwate
rloo.ca (Michael Coffin) writes:
   In article <1992Mar23.222808.6567@newshost.lanl.gov> jlg@cochiti.lanl.gov (J
im Giles) writes:

   > The fact is that most numerical/scientific programs don't contain
   > many reductions other than summation - which they contain lots of.
   > So, it makes some sense to provide summation in the form that's 
   > most convenient.  Further, the other reductions that are used, are
   > so rara (and often used in different contexts entirely), that some
   > more explicit notation, distinct from summation, might be desireable
   > just to emphasize the less usual operation.  Note, the most common
   > reductions other than sum in numerical/scientific programs are min and
   > max - reductions which have entirely different semantics from sum and
   > product - so they have to be done differently anyway.

   I think we ought to be a little careful of this argument.  People tend
   to use what is available---what is in their standard vocabulary.  In
   mathematics, sum and product have well-known symbols, so people use
   them.  Other reductions don't, so people aren't in the habit of using
   them.  Users of J have general reductions as part of their normal
   vocabulary, so uses for reductions of various kinds are seen
   everywhere.  

----
Good points all.  There is another reason for careful
use of the argument.  Programming practices will soon
need to change radically to accommodate parallel 
computations.  Various as yet unfamiliar reductions
will likely become commonplace in the coming computing 
environment.  A language designer needs to anticipate
the trends as well as acknowledge the status quo to
avoid frustrating the programmers who will become his
customers.

--
----
Mark E. Slagle                                 PO Box 61059
slagle@lmsc.lockheed.com                       Sunnyvale, CA   94088
408-756-0895                                   USA


======================================================================= 104 ===
Date:    Thu, 26 Mar 92 02:47:31 PST
From:    msm@.dec.com (Mark S. Manasse)
Subject: Re: Image object types for Modula-3


Here's what's currently available in bits and pieces of the Trestle
distribution:

VBT.i3 exports PaintScrnPixmap, which gives you a way to take a ScrnPixmap.T
and image into a VBT.  You create ScrnPixmap.T's through the ScrnPixmap.Oracle
in your VBT's screentype.  You have to take care to free such pixmaps when
you're done with them: the storage in your address space goes away, but
the pixmap that we allocate in the X server won't, since we don't have
any kind of object cleanup yet.

To build your ScrnPixmap.T, you need to start with a ScrnPixmap.Raw, which
is just a bunch of bits, and some rules for figuring out which pixel is
where.  You can look in the source for PixmapFromXData.m3 to see how I
build a ScrnPixmap.Raw from a pile of characters for in X format bitmap;
it's in the library for the card images used in 'solitaire'.

This will all work, but it will be pretty slow.  At present, I don't know
of existing code for converting other popular image formats (like XPM or
GIF or ...) into ScrnPixmap's.

In the next month or two, I'll be shipping a version of Trestle which exposes
more of X to those clients that have special needs.  In particular, if you
can somehow get your hands on the data you want to display in an X image
structure, we'll be providing a procedure that lets you paint that onto
your display.  If you set it up right, it will even use X's shared memory
transport if available.  This interface will NOT be safe, but it may be useful.
You'll also be able to set things up so that you can take an X pixmap, and
build a ScrnPixmap.T out of it.  So if you have a way (using raw X, say) to
get a bunch of stuff put into an X pixmap, you'll be able to display it.

There'll be more stuff in that interface: ways to use the X server connection
for a given Trestle.T; ways to extract the window id associated with a Trestle
window, or the cursor id associated with a Trestle cursor, etc.  It won't
make it really easy to use baroque X features, but it should make it possible.

Mark


======================================================================= 105 ===
Date:    26 Mar 92 09:56:21 GMT
From:    laverman@cs.rug.nl (Bert Laverman)
Subject: REVEAL; what does it really do?


  I'm trying to understand the effects of the REVEAL clause.
Suppose I have the following two interfaces:

    INTERFACE List_1;
      TYPE T <: ROOT;
      REVEAL T = BRANDED OBJECT next : T END;
    END List_1.

    INTERFACE List_2;
      TYPE T = BRANDED OBJECT next : T END;
    END List_2;

What is the difference?
  Am I correct in my understanding that there is no difference
between the information exported by List_1 and List_2? I suppose
the real use pops up when I want to define a list type _without_
exporting the knowledge that there is a 'next' field, as in:

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

    MODULE List_3;
      REVEAL T = BRANDED OBJECT next : T END;

      ...
    END List_3.

  Is this the reason for REVEAL?

Greetings, Bert

-- 
#include <std/disclaimer>

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


======================================================================= 106 ===
Date:    26 Mar 92 11:33:08 GMT
From:    collberg@dna.lth.se (Christian S. Collberg)
Subject: Checking Subtype relationships.

Judging from the source of the SRC compiler (v1.6), ISTYPE and other
subtype-checking functions use an O(1) algorithm. Has this been 
described in the literature, and if so where? If not, can someone
give me a brief description?

Thanks!

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


======================================================================= 107 ===
Date:    26 Mar 92 15:32:29 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: REVEAL; what does it really do?

Laverman noted that doing T <: ROOT and having a complete revelation of T in
the same scope does not really accomplish much. I think this is true. The
point is to be able to say T <: ROOT (or <: some other type) in one place, but
hide the details and reveal them only in certain other scopes -- the usual
information hiding / encapsulation sort of features one wants for programming
in the large. It so happens that in M3 these mechanisms have been decoupled
from the modularization constructs, unlike many other languages. This
flexibility is probably good, but (like any other feature) can be misused. It
also is yet another example of the tension between separate compilation and
information hiding on the one hand, and global optimization (which requires
more and more complete information to do a good job) on the other. In this
case, the problem is that in compiling a module we may know T <: ROOT, and
have another type S defined in terms of T, and know everything about how S
extends T, yet we still cannot determine offsets of fields of S without having
the revelation for T. Thus, information can be hidden even from subtype
implementors, again a good thing on balance, I believe, but a problem in
trying to achieve the best performance, etc.
--

		J. Eliot B. Moss, Assistant Professor
		Department of Computer Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu


======================================================================= 108 ===
Date:    26 Mar 92 14:54:12 GMT
From:    moss@cs.umass.edu (Eliot Moss)
Subject: Re: Checking Subtype relationships.

I know of two O(1) algorithms for checking subtype relationships. The one used
in the SRC M3 system relies on the fact that the hierarchy is *static*.  It
works as follows. Arrange all the object types of the program into a tree,
with ROOT as the root of the tree. Walk the tree and mark each node with its
pre-order and post-order number (these are the same for leaves). Now note that
S <: T iff pre(T) <= pre(S) <= post(T). The pre and post numbers
can be stored and accessed in O(1) time, so the algorithm is O(1).

Another algorithm I know of (I invented it myself, but am reasonably sure
others have invented it independently) does not rely on having a static
hierarchy. It works as follows. Associate with each type its level in the
hierarchy, e.g., ROOT is at level 1, immediate subtypes of ROOT are at level
2, etc. With each type at level i, associate a vector of its supertypes
(including itself, for simplicity). Now S <: T iff level(S) >= level(T) and
supers(S)[level(T)] = T. This is also O(1) in time, but may be O(t^2) in space
whereas the other algorithm is O(t) in space (t = number of types in the
system). We will probably use the level algorithm in GNU M3 since we want to
build Persistent M3, which at some point in the future will mean dynamic
loading of types, implying a dynamically changing hierarchy. We might be able
to adapt the numbering algorithm to dynamic situations, though ....

Both algorithms fail if you introduce multiple inheritance.
--

		J. Eliot B. Moss, Assistant Professor
		Department of Computer Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu


======================================================================= 109 ===
Date:    26 Mar 92 18:30:26 GMT
From:    chased@rbbb.Eng.Sun.COM (David Chase)
Subject: Re: Checking Subtype relationships.

In article <MOSS.92Mar26095412@ibis.cs.umass.edu> moss@cs.umass.edu writes:
>I know of two O(1) algorithms for checking subtype relationships. The one used
>in the SRC M3 system relies on the fact that the hierarchy is *static*.  It
>works as follows. Arrange all the object types of the program into a tree,
>with ROOT as the root of the tree. Walk the tree and mark each node with its
>pre-order and post-order number (these are the same for leaves). Now note that
>S <: T iff pre(T) <= pre(S) <= post(T). The pre and post numbers
>can be stored and accessed in O(1) time, so the algorithm is O(1).

Additional data structures can be built from this numbering allowing
an O(log number of cases) typecase implementation.  My first knowledge
of this trick comes from a chapter in the not-yet-published
Zadeck-Rosen-Allen compiler book; it almost certainly appeared before
this, because Paul Dietz published an algorithm for doing the fast
typecase (not under that name) in STOC '81 or '82.

> [other algorithm deleted] ... We might be able
>to adapt the numbering algorithm to dynamic situations, though ....

Yes, this is possible, depending upon your multiprocessor consistency
contraints.  If you assume that writes are seen in the order that they
are executed (or if they are seen in that order if the writes are
separated by a barrier instruction) then one can sweep through the
type tree in such a way that "failure" means either "real failure" or
"lost a race".  Since real failure is typically expensive, it is
reasonable to iteratively follow parent pointers to double-check the
failure.  (I heard of this trick from Roger Hoover.)  However, this
doesn't seem to work for the typecase check.  Some people (e.g., me)
think about this from time to time, since these algorithms have other
uses.  There is a paper by Dietz and Sleator on maintaining order in a
list (1987, some ACM conference, sorry for the faulty reference) that
may help here, but we haven't pushed concurrency into it yet.

>Both algorithms fail if you introduce multiple inheritance.

I heard that there was some paper (in TOPLAS, I think, last year or
two) on efficiently performing lattice operations that might be of
some help here.  That's all I know for now -- I have't had time to get
to it.

David Chase
Sun


======================================================================= 110 ===
Date:    26 Mar 92 15:42:38 GMT
From:    dagenais@vlsi.polymtl.ca (Michel Dagenais)
Subject: Re: SIGPLAN Modula-3 BOF

> I just looked at the advance program for SIGPLAN '92 in San Francisco,
> June 15-19. Many of the tutorial and symposium topics are relevant to
> Modula-3, and it appears that our friends from Princeton and U. Mass.
> will be giving papers on Modula-3-related topics.
>
> Looks like a good opportunity for a big Modula-3 get-together!

Good idea, i feel a bit lonesome using M3 in Montreal, i will make the 
arrangements in the next few days. (Please Bring your M3 sweat-shirts). 
Presumably some people from DEC SRC will be there and a visit to the M3 
national monument can be arranged. Let's get a Modula 3 BOF or even a 1/2 day
informal workshop going!
--
---------------------------------------------------------------------

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

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


======================================================================= 111 ===
Date:    26 Mar 92 21:22:56 GMT
From:    harbison@bert.pinecreek.com (Sam Harbison)
Subject: Re: REVEAL; what does it really do?

In article <9203261946.AA19511@toaster.SFSU.EDU> frode@toaster.SFSU.EDU (Frode 
Odegard) writes:
>...
>Can someone come up with an illustrative example of using multiple
>levels of revelations in several interfaces ?
>...

Yes, it happens I'm writing a paper on (a generalization of) this
topic. The basic idea: If you are going to use objects to provide an
extensible abstraction, you will probably end up with three layers of
revelations: a client interface, a "VAR interface" (from "value-added
reseller") for programmers extending the abstraction, and an
implementation module. In Modula-3, this maps naturally to three
units:

X.i3: 
   INTERFACE X;
   TYPE T <: Public;
        Public = OBJECT (*...visible stuff for clients...*) END;
   ...
   END X;

X_VAR.i3
   INTERFACE X_VAR;
   IMPORT X;
   REVEAL T <: VAR;
          VAR = X.Public OBJECT (*...stuff for VARs...*) END;
   ...
   END X_VAR;

X.m3
   MODULE X EXPORTS X, X_VAR;
   REVEAL T = VAR BRANDED OBJECT (*...internal stuff...*) END;
   ...
   END X;

The client interface provides the user-level methods, the VAR interface
provides the additional hooks for people extending the class X.T, and
the module provides the implementation details for the specific X.T
class.

Why the VAR interface? It is often not effective to extend a
high-level class by directly overriding its "client" methods--these
methods are usually at too high a level, e.g., "Deduct a recurring fee
from a 401-K account." Overriding these methods would just force you
to rewrite a lot of code you'd rather reuse.  Instead, the original
client methods are designed so that they call other "VAR" methods that
do the interesting pieces of work and that can be overridden without
having to reimplement the class' "infrastructure.  A real-world
example of this kind of architecture is the MacApp application
framework for the Macintosh.

Modula-3's opaque types provide an excellent mechanism for really
hiding information in these interfaces. However, this kind of
polymorphic OO architecture is inherently more complicated than pre-OO
module-based software architectures, and should only be used when the
kind of extensibility it provides is really necessary. Otherwise,
IMHO, you should stick with the simpler non-OO interfaces and modules.

In C++, classes provide the only clean mechanisms for encapsulation
and information hiding, and so classes are used even to implement
simple (non-extensible) software architectures.  That's OK, but I
think C++ programmers take the next step--into inheritance and
polymorphism--much too quickly. A good, extensible class structure is
much harder to design and use. If you don't need it, don't use it.

BTW, the problems don't show up very much in the small examples of OOP
we see in textbooks (including mine). I'm talking about Big Time,
application-level classes here, not just circles and stacks. It's also the
big classes where the advantages of code reuse are greater.

Sam Harbison 
Pine Creek Software; Suite 300; 305 South Craig Street; Pittsburgh, PA 15213;
USA. Phone&FAX: +1 412 681 9811. E-mail: harbison@bert.pinecreek.com.


======================================================================= 112 ===
Date:    Thu, 26 Mar 92 15:26:35 PST
From:    muller@src.dec.com (Eric Muller)
Subject: Re: Checking Subtype relationships.

In article <MOSS.92Mar26095412@ibis.cs.umass.edu>, moss@cs.umass.edu (Eliot Mos
s) writes:

> Both algorithms fail if you introduce multiple inheritance.

The Life programming language has a fairly elaborate scheme to handle
multiple inheritance while keeping the runtime test cheap.  I don't
know if it has been published, nor do I remember well enough how it
works to describe it.

---
Eric.



======================================================================= 113 ===
Date:    Thu, 26 Mar 92 16:05:37 PST
From:    <gnelson@src.dec.com>
Subject: Re: REVEAL; what does it really do?


Frode Odegard asks for an illustrative example of using multiple
levels of revelations in several interfaces.

There is an extended example in Chapter 6 of Systems Programming with
Modula-3 (Prentice-Hall, edited by G. Nelson).



======================================================================= 114 ===
Date:    Thu, 26 Mar 92 11:46:31 PST
From:    frode@toaster.SFSU.EDU (Frode Odegard)
Subject: Re: REVEAL; what does it really do?

> Suppose I have the following two interfaces:
>
>    INTERFACE List_1;
>      TYPE T <: ROOT;
>      REVEAL T = BRANDED OBJECT next : T END;
>    END List_1.
>
>    INTERFACE List_2;
>      TYPE T = BRANDED OBJECT next : T END;
>    END List_2;
>
> What is the difference?

In the first interface, you first say that T is a subtype of
ROOT.  But then you give a complete revelation, showing that
T is - concretely - BRANDED OBJECT next : T END.  Since, T
isn't revealed with an explicit supertype, ROOT becomes the
supertype.  List_2.T is fully declared, with ROOT as its
implicit supertype, also.  Thus List_1.T and List_2.T are
structurally equivalent, meaning "the same" in the Modula-3
type system.

> [..] I suppose the real use pops up when I want to define
> a list type _without_ exporting the knowledge that there
> is a 'next' field, as in:
>
>    INTERFACE List_3;
>      TYPE T <: ROOT;
>    END List_3.
>
>    MODULE List_3;
>      REVEAL T = BRANDED OBJECT next : T END;
>
>      ...
>    END List_3.
>
>  Is this the reason for REVEAL?

REVEAL is used to reveal information about an opaque type.  In
Modula-2, an opaque type had to be elaborated by simply redeclaring
it as a pointer type.  In Modula-3, the keyword REVEAL is used
instead of TYPE.

In Modula-3, partial revelations about T may occur in several
interfaces.  This can be confusing to a Modula-2 programmer.  However,
there can only be one concrete type for T, meaning: only one full
revelation.  All other revelations must be partial.  Multiple
revelations can be useful when one wants to look upon a type from
different perspectives.


Can someone come up with an illustrative example of using multiple
levels of revelations in several interfaces ?


				- Frode
--------------------------------------------------------------------
Frode Odegard, Odegard Labs, 100 Bush Street, Suite 625, San
Francisco, CA 94104, USA, +1-415-434-4242, +1-415-982-3167 (fax),
+1-415-905-6201 (voice mail), frode@toaster.sfsu.edu (internet),
frode (BIX)


