HDTenEightyP/NetNews huggingface dataset:
From: mikeg@psg.com (Mike Gallo)
Subject: Re: Oberon vs Modula-2 (Re: mail delivery error)
Organization: Pacific Systems Group, Portland Oregon US
Date: Fri, 20 Nov 1992 01:40:05 GMT

In article <1992Nov19.104407.338@jyu.fi> sakkinen@jyu.fi (Markku Sakkinen) writes:
>In article <1992Nov17.155855.4413@let.rug.nl> bert@let.rug.nl (Bert Bos) writes:
>>In article <1992Nov16.080647.26783@informatik.uni-ulm.de>, borchert@titania.mathematik.uni-ulm.de (Andreas Borchert) writes:
>>> Agreed, programmers shouldn't be enforced to use VAR-parameters
>>> for reasons of efficiency only. But, even with the semantics of
>>> Oberon or Modula-2, it's not to difficult for the compiler to
>>> detect that your 1000 x 1000 array isn't modified and, thus,
>>> doesn't need to be copied.
>>> ...
>>But what about a PROCEDURE p(a: Type; VAR b: Type) that is called as p(x, x). Both parameters will refer to x, but if b is modified, a should remain unchanged.
>
>A good point, showing that my suggestion of constant vs. variable
>is worse that value vs. variable as far as regards aliassing problems.
>Thus, there would indeed be some merit in having three parameter modes
>(as somebody suggested in this thread):
>value, constant, and variable (and possibly yet something like 'out'
>in Ada, i.e. a result parameter).

The Turing language offers two paramter modes, variable and
"constant".  Their solution to the above problem is that actual
variable parameters must be unique, although the above sort of problem
was not the explicit reason for doing so.  Their justification was
that the logic of the procedure assumes that different variable
parameters are different variables, and so the compiler shoulf enforce
it.  

Newsgroups: comp.lang.modula2
From: pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
Subject: Re: Modula-3
Reply-To: pk@rwthi3.informatik.rwth-aachen.de
Organization: Lehrstuhl fuer Informatik III, RWTH Aachen, Germany
Date: Sun, 22 Nov 92 19:09:40 GMT

In article 2B0CFFB3@puddle.fidonet.org, Rt.Pollock@f414.n229.z1.fidonet.org (Rt Pollock) writes:
>This enquiry is being made on behalf of a local friend who is 
>looking for information regarding MODULA-3; indeed, until he had 
>asked me about this, I wasn't even aware that Wirth had revamped the 
>language. Between the two of us, we're completely at a loss over 3.
> 
Modula-3 is not by Wirth, it has been developed by DEC and Olivetti.

>Are there any recommendations over 3's suppliers ? 
Right now, there is only one compiler (from DEC SRC). A second system is under
development in a GNU project.

Where ?
At gatekeeper.dec.com in pub/DEC/Modula-3.

How much ?
Free.

>What are the virtues of 3 over 2 ? 

Modula-3 has almost everything you always missed in Modula-2. It is generally a
Modula-2 superset with the following major enhancements:
- garbage collecion
- exception handling
- single inheritance
- light weight processes
- generics
Some of the minor points are record and array constructors, named parameter
passing, default values for record fields and formal parameters, and a
built-in type for strings. And it buys you all this without making the
language overly complicated.

For more details, get the Modula-3 FAQ (at gatekeeper) and take a look at
comp.lang.modula3.

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

Newsgroups: comp.lang.modula2
From: bert@let.rug.nl (Bert Bos)
Subject: Re: Oberon vs Modula-2 (Re: mail delivery error)
Organization: Faculteit der Letteren, Rijksuniversiteit Groningen, NL
Date: Tue, 17 Nov 1992 15:58:55 GMT

In article <1992Nov16.080647.26783@informatik.uni-ulm.de>, borchert@titania.mathematik.uni-ulm.de (Andreas Borchert) writes:
> Agreed, programmers shouldn't be enforced to use VAR-parameters
> for reasons of efficiency only. But, even with the semantics of
> Oberon or Modula-2, it's not to difficult for the compiler to
> detect that your 1000 x 1000 array isn't modified and, thus,
> doesn't need to be copied.
> 
> Usually, the calling procedure passes a reference to the array onto
> the stack in both cases and the called procedure then makes a copy
> of the array if you have call-by-value and your array parameter
> is subject to changes.

But what about a PROCEDURE p(a: Type; VAR b: Type) that is called as p(x, x). Both parameters will refer to x, but if b is modified, a should remain unchanged.
From: Simon.Meacham@newcastle.ac.uk (Simon Meacham)
Newsgroups: comp.lang.modula2
Subject: Mouse drivers
Summary: Mouse Drivers/Modules for JPI Modula 2 needed.
Keywords: Mouse
Date: 18 Nov 92 17:09:40 GMT
Organization: University of Durham, UK.
X-Newsreader: TIN [version 1.1 PL6]

Hi, I'm having to do a project, the specifications for which demand that
I support the use of a mouse with the Text Windowing system supplied in
JPI Modula2.

Does anyone know of a site somewhere, or has themselves written a mouse
support module I could get hold of. I'd be most grateful.

Thanks for your time, all email replies gratefully recieved :)

Best Regards

Simon.

--
Simon.Meacham@uk.ac.durham
Disclaimer: "All the above are not my beliefs, merely the products of my
             own deranged imagination."
Newsgroups: comp.lang.modula2
From: uesu03@giac1.oscs.montana.edu (Lou Glassy)
Subject: Request:  recommendations for books on Oberon
Organization: Montana State University, Bozeman  MT
Date: Mon, 23 Nov 1992 19:58:45 GMT

I've read the papers on Oberon by N. Wirth as published in _Software
Practice & Experience_.  Can anyone recommend to me a good book or
books for learning Oberon?

Something like PIM2 3ed was? (That's what I learned Modula from.)

I've laid my grubbies on a copy of Ed Videki's Oberon-M compiler for
DOS boxes.  I found the standard IO to be positively bizarre, compared
to what I was used to in M2's InOut and RealInOut.

(That's no slam either to Oberon or the Oberon-M implementation.  It's
just that I'm no rocket scientist, and thus would greatly benefit from
being able to get a good, basic Oberon reference.)

Thanks in advance,

Lou.

-- 
Lou Glassy (uesu03@giac1.oscs.montana.edu)   Watch the field behind the plow
Earth Sciences Department                    Turn to straight, dark rows
Montana State University                     Put another season's promise
Bozeman, Montana 59715 USA                   In the ground...  --Stan Rogers
Newsgroups: comp.lang.modula2
From: mgmam@uxa.ecn.bgu.edu (Mark A. Morrell)
Subject: Re: executing from within a modula-program
Organization: Educational Computing Network
Date: Mon, 16 Nov 1992 17:01:36 GMT

In article <1992Nov12.101226.10318@hippo.ru.ac.za> apj@beldin.sun.ac.za (Andries Dippenaar) writes:
>Mark A. Morrell (mgmam@uxa.ecn.bgu.edu) wrote:
>:  > I use Topspeed modula 3.1 and had a problem in my last program. Does
>:  > anyone know how Ii can execute another program from a modula program so
>: 
>: This is a procedure which stuffs a character into the keyboard buffer,
>: and may be of use to you.  Stuff the buffer, then exit your program.
>: 
>  [stuff deleted]
>
>That's not one of the better ways of doing it.  TopSpeed supplies an
>Execute procedure in Lib if I remember correctly.  They've actuallt
>got two flavours, Execute and ExecuteCmd.  The former can only be used
>to execute binaries (ie. .COM or .EXE files) and the latter is passed
>a complete DOS commandline (like C's system command) which is then
>executed under COMMAND.COM (actually %COMSPEC) so that you can also
>run batch files.  The easiest way to locate it in the libaries is to
>type it in the editor, put the cursor over it and hit F1.

Well, the message requested a way to leave the program, and then execute
the command.  Neither of these will do that for you.  BTW, there is a
third flavor to execute a command within JPI M2:  Exec.  The Execute
command requires you to allocate space for the program to run in, and
the Exec command does not.  Exec also allows you to pass an alternate
DOS environment to the command, while Execute does not.
-- 
--------------------------------------------------------------------
Mark A. Morrell     Disclaimer:  _I_ probably don't even believe it.
Literary Reference:  The introduction to Cervantes' Don Quixote.

Newsgroups: comp.lang.modula2
From: John.Mcmonagle@f590.n139.z1.fidonet.org (John Mcmonagle)
Newsgroups: comp.lang.modula2
Subject: Re: MODULA 2 PROGRAM USING BL
Date: 18 Nov 92 03:44:10 GMT
Article-I.D.: puddle.20502.2B0A05F8
Organization: FidoNet node 1:139/590 - PMI BBS, Green Bay WI


 TS>     ASB>I'm looking for a Modula 2 program which does 
 TS> realy large calculations
 TS>     ASB>on matices and vectors. (The Matrix should 
 TS> have a few thousand rows!)
 TS>     
 TS> PMI (the Repertoire company) has a package with
 TS> sparse matrix calculations.

 Torbjorn 

 Thanks I forgot to respond to the previous message.
 It has been a long time since I've done linear algebra but from 
 what I can see  DynaMatrix has about everything one should need
 for linear algebra for real numbers. 

 I'll get a demo put together and make it available. James Bones
 took numerical analysis seriously and put together a nice package.

John McMonagle
	
-----------------------------------------------------------
| (414)468-6040 voice (414)465-0464 fax (414)465-1656 bbs | | PMI                     BIX as PMI                      | | 3279 N Nicolet Drive    zzmcmonaglej@gbvaxa.uwgb.edu    |
| Green Bay, WI 54311     Fidonet 1:139/590     	  |
-----------------------------------------------------------


--  
uucp: uunet!m2xenix!puddle!139!590!John.Mcmonagle
Internet: John.Mcmonagle@f590.n139.z1.fidonet.org
From: Jon.Guthrie@p25.f2000.n106.z1.fidonet.org (Jon Guthrie)
Newsgroups: comp.lang.modula2
Subject: StonyBrook Modula Updates ?????
Date: 14 Nov 92 04:21:04 GMT
Article-I.D.: puddle.20385.2B0997E6
Organization: FidoNet node 1:106/2000.25 - COMM Port One, Sugar Land TX

Jai Braatz (1:208/401.1) writes to Jon Guthrie:

 >> The next version should be in beta-test by now.  Some six 
 >> weeks ago, I called Stony Brook and they said that their 
 >> next release was being prepared for beta.

 >Where can I purchase a copy of this (even if it's not the new 
 >version expected out?)

I got mine from the Programmer's Connection.  You can also call StonyBrook at 800-624-7487 (in the USA) or 805-496-5837 (outside of the USA.)  I'd bet that a mail-order house would be cheaper.


--  
uucp: uunet!m2xenix!puddle!106!2000.25!Jon.Guthrie
Internet: Jon.Guthrie@p25.f2000.n106.z1.fidonet.org
Newsgroups: comp.lang.modula2
From: pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
Subject: Re: Oberon vs Modula-2 vs Modula-3
Reply-To: pk@rwthi3.informatik.rwth-aachen.de
Organization: Lehrstuhl fuer Informatik III, RWTH Aachen, Germany
Date: Sun, 22 Nov 92 18:55:30 GMT

In article 338@jyu.fi, sakkinen@jyu.fi (Markku Sakkinen) writes:
>A good point, showing that my suggestion of constant vs. variable
>is worse that value vs. variable as far as regards aliassing problems.
>Thus, there would indeed be some merit in having three parameter modes
>(as somebody suggested in this thread):
>value, constant, and variable

This is exactly what Modula-3 has: VAL, READONLY and VAR.

In article 18702@informatik.uni-ulm.de, borchert@titania.mathematik.uni-ulm.de (Andreas Borchert) writes:

>Readonly parameters don't protect from surprises. E.g. if we have
>the above mentioned
>
>   PROCEDURE p(a: Type; READONLY b: Type);
>   BEGIN
>      a[1] := ....;
>      (* has b[1] been changed now? *)
>   END;
>
>where p is called as p(x, x). And all other cases are still not solved
>where formerly VAR-parameters have been threatened by other procedures
>in a non-obvious way.

What is surprising about this? The semantics of the example is obvious
(at least in Modula-3). b[1] is not changed, of course. a is passed by
value, so the global x (and therefore b) is not changed by the assignment.

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

Newsgroups: comp.lang.modula2
From: heli@eichow.tuwien.ac.at (Helmut Dier)
Subject: Re: FWD>modula-2
Reply-To: heli@eichow.tuwien.ac.at
Organization: Tech. University Vienna, Dept. of Computergraphic
Date: Tue, 17 Nov 1992 08:32:14 GMT

Try 147.28.0.33 or 192.83.230.1  (ftp.msg.com)

Helmut
----------------------------------------------------------------------
Helmut Dier,                     | E-Mail:
sutdent of computer science,     | Internet: 
                                 |   HELI@EICHOW.UNA.AC.AT
Technical Universitiy of Vienna  |   HELMUT@ATLAS.SMC.UNIVIE.AC.AT
                                 |   HELMUT@PCBT153.SMC.UNIVIE.AC.AT
                                 |   A4421DBD@AWIUNI11.EDVZ.UniVie.AC.AT
Austria, Europe                  | Bitnet:
Newsgroups: comp.lang.modula2
From: tchannon@black.demon.co.uk (Tim Channon)
From: cheryl@gallant.apple.com (Cheryl Lins)
Newsgroups: comp.lang.modula2
Subject: Re: Oberon vs Modula-2
Summary: Oberon wins 6-0!
Date: 23 Nov 92 17:52:51 GMT
Organization: Apple Computer Inc, Cupertino, CA

In article <1992Nov23.124207.9204@neptune.inf.ethz.ch> templ@inf.ethz.ch (Josef Templ) writes:
>But, wouldn't it be nice to resolve these ambiguities by removing
>local types (and procedures and constants) from the language?

I'm all for it. Just by eliminating nested procedures you get rid of these
problems. You also make the language simplier. You make compilation easier.
Optimization is easier (less aliasing for starters).

And I don't what to here the excuse the 'we have too much software written at
ETH that use these features to eliminate them now'. Look at C and C++. Some 
of the worst features of these languages originated because the designer(s)
wanted to remain compatible with some earlier language (C with BCPL, C++ with C)
. Plus, maintaining software would be good experience for students. It's
something they'll have to do a lot in the real world.
-- 
Cheryl Lins  Oberon Paladin  lins@apple.com
"Beware the following code - I've only proven it correct, not tested it" Knuth
Newsgroups: comp.lang.modula2
From: seurer@rchland.vnet.ibm.com (Bill Seurer)
Subject: Re: Mouse drivers
Date: Thu, 19 Nov 1992 14:39:13 GMT
Reply-To: BillSeurer@vnet.ibm.com
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM Rochester
Keywords: Mouse

JPI comes with a mouse support module, MSMouse.  Why not just use that?
-- 

- Bill Seurer     Language and Compiler Development      IBM Rochester, MN
  Internet: BillSeurer@vnet.ibm.com    America On-Line: BillSeurer@aol.com
Newsgroups: comp.lang.modula2
From: templ@inf.ethz.ch (Josef Templ)
Subject: Re: Oberon vs Modula-2
Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Sat, 21 Nov 1992 09:53:07 GMT


A. Borchert writes:
> Here an example, following program is perfectly legal Oberon text
> but rejected by the Sparc Oberon System from ETH Zurich:
> 
> (* CLASS=CONFORMANCE *)
> MODULE t03;
>    TYPE c = RECORD a, b: INTEGER END;
>    PROCEDURE e;
>       TYPE b = POINTER TO c;
>          c = ARRAY 3 OF CHAR;
>       VAR p: b;
>    BEGIN (* e *)
>       p^[1] := "x";
>    END e;
> END t03.
> The compiler complains at the designator >>p^[1]<< that
> "indexed variable is not an array".

Section 4 (Declarations and Scope rules) of the Oberon-2 Report:
  The scope of an object x extends textually from the point of its declaration 
  to the end of the block (module, procedure, or record) to which the 
  declaration belongs and hence to which the object is local.

and in the same section:
  A type T of the form POINTER TO T1 (see 6.4) can be declared before
  the scope of T1. In this case, the declaration of T1 must follow in
  the same block to which T is local;

I think this is an ambiguity in the language definition.
The forward declaration rule should be explicitely restricted to
the cases where T1 is not visible at the point of the forward declaration.
Anyway, the intention is that the above program is neither legal
Oberon nor legal Oberon-2.


> MODULE RecAssignment;
>    TYPE T0 = RECORD END;
>         T1 = RECORD (T0) END;
>    VAR t1a, t1b: T1;
>    PROCEDURE AssignIt(VAR ta, tb: T0);
>    BEGIN
>       ta := tb; (* statically the same type and ... *)
>    END AssignIt;
> BEGIN
>    AssignIt(t1a, t1b); (* ... dynamically the same type *)
> END RecAssignment;
> 
> is perfectly legal in Oberon but not in Oberon-2. But, of course,
> this feature was never implemented in ETH compilers (tell me if
> I'm wrong here).

Both Oberon and Oberon-2 compilers will compile the above module.
The context condition "Te and Tv are record types and Te is an extension
of Tv and the dynamic type of v is Tv" cannot be fully checked at compile time
but compiles into a runtime check in both Oberon and Oberon-2.
The original Oberon-Report does not mention implicit runtime
checks (c.f. array indices, ...).

- Josef Templ
the usual disclaimer applies
From: WPK@cup.portal.com (WPK - micromedia)
Newsgroups: comp.lang.modula2
Subject: Re: Modula-3
Date: Sun, 22 Nov 92 05:15:11 PST
Organization: The Portal System (TM)

>looking for information regarding MODULA-3; indeed, until he had
>asked me about this, I wasn't even aware that Wirth had revamped the
>language. Between the two of us, we're completely at a loss over 3.
>
>Semper Fi

Modula-3 is not designed by N. Wirth. In fact, it takes a totally
different approach than W's Oberon design.

DEC's SRC and ?RC (oops, forgot...) research centers designed, and
implemented it.

O|O
 v   WPK                                                           _
                     W P K  m i c r o m e d i a                 _ //
----------------------------------------------------------------\X/---
 La Puente, Calif.    fax: (818)369-4797    email: WPK@cup.portal.com
Newsgroups: comp.lang.modula2
From: borchert@titania.mathematik.uni-ulm.de (Andreas Borchert)
Subject: Re: Oberon vs Modula-2
Organization: University of Ulm, SAI
Date: Mon, 23 Nov 92 06:32:39 GMT

In article <1992Nov22.125424.28252@neptune.inf.ethz.ch>, templ@inf.ethz.ch (Josef Templ) writes:
> > MODULE t03;
> >    TYPE c = RECORD a, b: INTEGER END;
> >    PROCEDURE e;
> >       TYPE b = POINTER TO c;
> >          c = ARRAY 3 OF CHAR;
> >       VAR p: b;
> >    BEGIN (* e *)
> >       p^[1] := "x";
> >    END e;
> > END t03.
> 
> S. Bevan writes
> > I'd call that more than an ambiguity.  My _interpretation_ of the
> > rules (and the one I implemented) was that the above program was
> > invalid, but that if you switched the order of "b" and "c" it would be
> > valid.  Is the above (jt) interpretation going to be made official at
> > some point? 
> 
> IMHO, our interpretations are exactly the same.
> It is the interpretation that evolves naturally from "single pass compilation".
> Unfortunately, the current report allows a different interpretation
> because it does not restrict the forward declaration rule to
> forward declarations. In this sense, the report is ambigous.
> It does not specify which c is to be taken as the pointer base type.
> If you switch b and c, there is no ambiguity even in the current report.

Hm, perhabs we are using different reports. The ETH language reports
change too often to be always up to date.

In the latest yellow report I received from ETH (report 111 from
September 1989) I find following statements in section 4 (declarations
and scope rules):

The scope extends textually from the point of the declaration to the end
of the block (procedure or module) to which the declaration belongs and
hence to which the object is local. The scope rule has the following
amendments:

   1. If a type T is defined as POINTER TO T1 (see 6.4), the identifier
      T1 can be declared textually following the declaration of T,
      but it must lie within the same scope.

I don't see any interpretation which allows the declaration "b = POINTER TO c"
to be bound to the previously declared type "c". The amendments take
precedence over the statements before (that follows clear from the text)
and, consequently, I may declare the referenced type even if there
exist the same identifier in the outer scope.

This is preferably -- for what reason should my local declarations depend
from the outer scope if they don't need the outer scope?

And there is no difficulty in implementing this definition in a
1-pass compiler: view all pointer declarations as forward-declarations
and delay the association to the first procedure or the body of
the procedure or module of the scope. Procedure declarations may not
be followed by other declarations -- so we don't come in to trouble.

-- 
_______________________________________________________________________________

Andreas Borchert, University of Ulm, SAI, D-W-7900 Ulm, Germany
Internet: borchert@mathematik.uni-ulm.de
Newsgroups: comp.lang.modula2
From: cheryl@gallant.apple.com (Cheryl Lins)
Subject: Re: Oberon vs Modula-2
Date: Mon, 16 Nov 1992 22:18:11 GMT
Organization: Apple Computer Inc, Cupertino, CA

In article <gpjqq!h+@aix01.rz.fht-mannheim.de> mw%ki.fht-mannheim.de (Marc Wachowitz) writes:

>Andreas Borchert (borchert@titania.mathematik.uni-ulm.de) wrote
>in reply to Markku Sakkinen <sakkinen@jyu.fi>:
>: Agreed, programmers shouldn't be enforced to use VAR-parameters
>: for reasons of efficiency only. But, even with the semantics of
>: Oberon or Modula-2, it's not to difficult for the compiler to
>: detect that your 1000 x 1000 array isn't modified and, thus,
>: doesn't need to be copied.
>
>That doesn't work as soon as your procedure is public and (directly or
>indirectly) calls some procedure not fully known to the compiler, since
>the original argument may be accessible and modified behind the back of the
>supposedly innocent routine. According to the current definition it only
>sees a copy made at the entry and therefore would not be influenced by the
>perfectly legal modification, but due to our smart optimizer ... :-(
>

Actually interprocedural side-effect analysis  and alias analysis are fairly
complex. See the references below. Very few production compilers implement
such analyses.

If the actual parameter is a globally exported variable, and the routine (call
it "p") calls through a procedure variable, it may be impossible at compile-
time to determine whether the actual parameter is modified or not.

While the symbol file could be enhanced to carry the interprocedural alias and
side-effect information (and this could improve the analysis in modules calling
imported procedures), there will still be situations where the compiler cannot
determine the full effects. Additional analysis could be done at link-time,
but a good deal of additional information would be necessary for a linker to
do this. Probably not impossible, just a lot of work.


@inproceedings{cooper:88b,
	author		= "Keith D. Cooper and Ken Kennedy",
	title		= "Interprocedural side-effect analysis in linear time",
	booktitle	= pldi88,
	journal		= sigplan,
	volume		= 23,
	number		= 7,
	pages		= "57--66",
	address		= "Atlanta, GA",
	month		= jun,
	year		= 1988}


@techreport{cooper:88c,
	author		= "Keith D. Cooper and Ken Kennedy",
	title		= "Complexity of interprocedural side-effect analysis",
	institution	= Rice,
	type		= "Technical Report",
	number		= "Rice COMP TR87-61",
	year		= 1988}

@inproceedings{cooper:89a,
	author		= "Keith D. Cooper and Ken Kennedy",
	title		= "Fast interprocedural alias analysis",
	booktitle	= popl89,
	pages		= "49--59",
	address		= "Austin, TX",
	month		= jan,
	year		= 1989}


-- 
Cheryl Lins  Oberon Paladin  lins@apple.com
"You bloated sack of protoplasm!" - Ren
Newsgroups: comp.lang.modula2