HDTenEightyP/NetNews huggingface dataset:
From: cheryl@gallant.apple.com (Cheryl Lins)
Newsgroups: comp.lang.modula2
Subject: Re: Oberon vs Modula-2
Summary: Forward refs to base types
Date: 23 Nov 92 17:41:29 GMT
Organization: Apple Computer Inc, Cupertino, CA

In article <1992Nov21.095307.19198@neptune.inf.ethz.ch> templ@inf.ethz.ch (Josef Templ) writes:
>
>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".
>
>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.
>

Of course, it's legal. It's just not what the programmer intended :-)
The "c" referred to in "b = POINTER TO c" is the record structure declared in
the outer scope. So obviously, using indexing on a record generates an error
in >>p[1]<<. 

-- 
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: borchert@titania.mathematik.uni-ulm.de (Andreas Borchert)
Subject: Re: Oberon vs Modula-2 vs Modula-3
Organization: University of Ulm, SAI
Date: Mon, 23 Nov 92 06:37:28 GMT

In article <1992Nov22.185530.26542@Urmel.Informatik.RWTH-Aachen.DE>, pk@rwthi3.informatik.rwth-aachen.de (Peter Klein) writes:
> 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);

OOPS, I forgot to insert VAR before "a", i.e. I was speaking about

      PROCEDURE p(VAR 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.

-- 
_______________________________________________________________________________

Andreas Borchert, University of Ulm, SAI, D-W-7900 Ulm, Germany
Internet: borchert@mathematik.uni-ulm.de
Newsgroups: comp.lang.modula2
From: sanders@inf.ethz.ch (Beverly Sanders)
Subject: CFP:  Conf. on Prog. Languages and System Architectures
Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Mon, 16 Nov 1992 12:24:49 GMT


                       Call for Papers

                        Conference on 

           Programming Languages and System Architectures
with a special session in honor of Niklaus Wirth on his 60th birthday


                     2th - 4th March, 1994
                    ETH Zurich, Switzerland


The conference will provide an international forum for the presentation 
and discussion of recent research in the areas of programming languages 
and system architectures. Authors are invited to submit papers describing 
original research related to these areas. Particularly encouraged are 
contributions discussing their mutual influence. Also, unrefereed 
contributions of 5-20 min. duration, and of a technical and/or personal 
nature are solicited for an afternoon session honoring N. Wirth.


Subjects of special interest include, but are not restricted to:

Programming language design and history, Programming environments, 
Programming methods, Operating systems, Compiler construction, 
Innovative system architectures


Send two copies of technical contributions to the program chair. 
Submissions should not exceed 15 pages and must not have been published 
or submitted for publication elsewhere. Where possible, include the 
e-mail address and fax number of the contact author. Potential contributors 
to the special session in honor of Niklaus Wirth should contact the program 
chair for more information.

Proceedings will be published by Springer Verlag in the Lecture Notes in 
Computer Science series and will be distributed at the conference.



Program Committee

J. Gutknecht (Chair)
ETH Zentrum
CH-8092 Zurich, Switzerland
e-mail: gutknecht@inf.ethz.ch
e-fax: (+41 1) 251 96 78

R. P. Cook, Microsoft, Redmond, WA
G. Coray, EPF Lausanne, CH
O. J. Dahl, University of Oslo, N
E. W. Dijkstra, Univ. of Texas, Austin, TX
G. Goos, Techn. Univ, Karlsruhe, D
S. Graham, Univ. of California, Berkeley, CA
D. Gries, Cornell University, Ithaca, NY
D. Hanson, Princeton Univ, Princeton, NJ
B. Kernighan, AT&T Bell Labs, Murray Hill, NJ
B. W. Lampson, DEC CRL, Cambridge, MA
J. Ludewig, Techn. Univ., Stuttgart, D
J. Misra, Univ. of Texas, Austin, TX
H. Moessenboeck, ETH Zurich, CH
R. Needham, Cambridge University, GB
S. Owicki, DEC SRC, Palo Alto, CA
G. Pomberger, Universitaet Linz, A
P. Rechenberg, Universitaet Linz, A
M. Reiser, IBM Research, Zurich, CH
B. Sanders, ETH Zurich, CH
P. Schulthess, Universitaet Ulm, D
A. Shaw, Univ. of Washington, Seattle, WA
P. D. Terry, Rhodes University, Grahamstown, SA
L. Tesler, Apple Corp, Cupertino, CA
J. Welsh, Univ. of Queensland, Brisbane, AU
N. Wirth, ETH Zurich, CH


Key Dates

Deadline for receipt of submissions: 1st August, 1993
Acceptance notification: 1st November, 1993
Deadline for camera-ready final papers: 15th December, 1993
From: mikeg@PSG.COM ("", Mike Gallo)
Newsgroups: comp.lang.modula2
Subject: Re: Oberon-2 discussion continues
Date: 16 Nov 92 07:17:00 GMT
Reply-To: Modula2 List <INFO-M2%UCF1VM.BITNET@uga.cc.uga.edu>
Distribution: world
Organization: Pacific Systems Group, Portland Oregon US

In article <9211130912.A01822@MAIL.CASI.NASA.GOV> you write:
>
>  The discussion of Oberon continues....
>
>  extension has been implemented at ETH but removed (according to one
>  person in ETH involved in the Oberon compilers)).
>
>  Incidentally, ASSERT is now a standard procedure in Oberon.
>
>  Taylor
>  thutt@mail.casi.nasa.gov
>  Championing worldwide usage of Oberon-2

Out of sheer curiosity, how do you get all this up to date info on
Oberon?  Is it a matter of knowinf the right people, or is there some
official source?

While I'm at it (though you're probably sick of the question), weren't
you writing an Oberon-2 compiler for DOS?  How goes that project?

Thanks for your time,
Mike
Oberon enthusiast
references: <1992nov16.080647.26783@informatik.uni-ulm.de>,<gpjqq!h+@aix01.rz.fht-mannheim.de>
From: mdlcpgs@lhn.gns.cri.nz
Newsgroups: comp.lang.modula2
Subject: Re: Oberon vs Modula-2
Date: Tue, 17 Nov 92 21:15:20 GMT  
Organization: Institute of Gelogical & Nuclear Sciences, New Zealand.

>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 ... :-(

Hobby horse time again! I will re-assert my belief that the Wirth languages
need other optional attributes on variable declarations and formal
parameter definitions besides just TYPE (and VAR in the case of formal
parameters).

Very useful are:  Static; (I dont like module level being only way to
declare static variables when the scope of variable may be only one
procedure. Local modules in M2 were about the most complicated away to
achieve what the a static identifier could do imaginable)
		  location; specifying the absolute memory address
of variable (yes I know M2 implementation allow this).
		  Readonly; More power to compiler for finding logic
errors and the solution to the by-value or by-reference versus
efficiency problem in format parameters;

Without these, we expect the compiler to perform miracles with limited
infomation. Adding them allows more power to compiler and efficency without
compromise of method.
	Phil
Newsgroups: comp.lang.modula2
From: jpussi@cs.joensuu.fi (Jarmo Pussinen)
Subject: Re: Oberon-2 discussion continues
Organization: University of Joensuu
X-Newsreader: Tin 1.1 PL5
Date: Mon, 23 Nov 1992 08:14:53 GMT

Benedict Rafanello (bmr@buoy.cis.ufl.edu) wrote:
: |> >>>  e) DEFINITION & IMPLEMENTATION merged.
: 
: |>  >>This was a really bad move.  Now you can't define the interface separately
: |>  >>and enforce it, and the "*" and "-" stuff is really kludgy, very atypical
: |>  >>of Wirth's work.  Even if you accept that merging the def and imp is good,
: |>  >>interface details like READONLY really deserve their own keywords.
: 
: |>  No, this is a good move.  The maintenance of only 1 file is a big
: |>  win.  If you are concerned about the definition being published with
: |>  the source, don't worry.  There is a `Browser' module which will
: |>  output a definition for a compiled module.  You can then ship the
: |>  defintion (sans comments, unless you provide them) with your object
: |>  modules.
: 
: If both the interface and the implementation are in one file, how do you
: tell when only the implementation was changed?  This is very important for
: large projects.  Some of the projects that I have been involved with contain
: more than a million lines of code.  These projects (done in Ada) would take
: several DAYS just to compile.  If the interface to a package was changed,
: we would have to go through that horrendous compile cycle whereas if just
: the implementation was changed, we only needed to relink.  How does Oberon
: handle this?
: 
: Ben

There is a compiler option, which tells to the compiler that interface 
may change. If you compile a source file without that option you cannot 
change the interface (create a new .sym file) without a compile time error.
So there is no need to recompile the other stuff (and as you know there is
no linking phase in Oberon :-), after changes that do not affect interface.

In short in Oberon it is the compiler which creates the interface file.
-- 
--------------------------------------------------------------------------------
| University of Joensuu                 |   When I was younger I always thought|
| jpussi@cs.joensuu.fi                  |   but nowadays I don't.              |
| or something like that                |                                      |
From: Simon.Meacham@newcastle.ac.uk (Simon Meacham)
Newsgroups: comp.lang.modula2
Subject: Re: Mouse drivers
Date: 20 Nov 92 11:43:05 GMT
Organization: University of Durham, UK.
X-Newsreader: TIN [version 1.1 PL6]

Bill Seurer (seurer@rchland.vnet.ibm.com) wrote:
: 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

We use a student version of JPI Modula2 here, and that doesnt come  with
as many modules. Some of the more advanced utilities are just not there,
and this includes the MSMouse support module, which is why I  can't  use
that  (believe  me I wish I could). Apparently the advantage to the dept
is they dont have to pay as much to buy all the copies  of  Modula2  and
count on the fact we're not going to need a lot of the advanced features
since we're only students. Only now they've set us a  project  demanding
we interface for a mouse... good eh?

Anybody got any ideas?

Cheers - 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: torbjorn@forit.forut.no (Torbjorn Sund)
Subject: Re: MODULA 2 PROGRAM USING BL
Organization: Norwegian Telecom/FORUT, Norway
Date: Mon, 16 Nov 1992 11:31:34 GMT

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

-----
Torbjorn Sund              	Norwegian Telecom Research
Telephone +47 83 10267     	P.O. Box 1156
Telefax   +47 83 10262     	N-9001 TROMSO
<torbjorn.sund@tft.tele.no>	NORWAY
From: andrea@ESSEX.STFX.CA (John Andrea)
Newsgroups: comp.lang.modula2
Subject: Re: MODULA 2 PROGRAM USING BL
Date: 18 Nov 92 13:13:16 GMT
Reply-To: Modula2 List <INFO-M2%UCF1VM.BITNET@uga.cc.uga.edu>
Distribution: world
Organization: The Internet

DynaMatrix -sounds nice, is it shareware, freeware, public ?

John Andrea                        email: andrea@essex.stfx.ca
VAX System Manager                 phone: (902) 867-2275
St.Francis Xavier University       fax:   (902) 867-5153
Antigonish, Nova Scotia
Canada   B2G 1C0
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.modula2
Subject: Re: Oberon vs Modula-2
Date: 21 Nov 92 10:24:49 GMT
	<BEVAN.92Nov18195812@tiger.cs.man.ac.uk>
	<1992Nov20.125458.25797@informatik.uni-ulm.de>
Organization: Department of Computer Science, University of Manchester
In-reply-to: borchert@titania.mathematik.uni-ulm.de's message of 20 Nov 92 12:54:58 GMT

In article <1992Nov20.125458.25797@informatik.uni-ulm.de> borchert@titania.mathematik.uni-ulm.de (Andreas Borchert) writes:
   In summary, Oberon and Oberon-2 are (at least for ETH) research
   projects and, thus, subject to changes and development. So, you've to
   decide whether you want to be ETH-compatible or close to one of the
   reports.

Question: If I can give more than one interpretation to a particular
aspect of the report and the ETH compiler produces output consistent
with one of those interpretations, how can I be sure that it is the
correct one?

Answer: You can't, that is what a formal definition is for.

bevan
Newsgroups: comp.lang.modula2
From: sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: Oberon vs Modula-2 (Re: mail delivery error)
Organization: University of Jyvaskyla, Finland
Date: Thu, 19 Nov 1992 10:44:07 GMT

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).

Fortran, I think, has a rule stating that if a formal parameter is
modified within a subprogram, the corresponding actual parameter must
not be the same as any other actual parameter in the call.
Does Modula-2 or Oberon have a similar rule?  (Value parameters need
not be considered, but constant parameters would if passed by reference.)
Of course, those breaches of the rule that cannot be detected at compile
time could be too expensive to catch at run time.

----------------------------------------------------------------------
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
----------------------------------------------------------------------
From: bmr@buoy.cis.ufl.edu (Benedict Rafanello)
Newsgroups: comp.lang.modula2
Subject: Re: Oberon-2 discussion continues
Date: 21 Nov 92 23:39:59 GMT
Organization: Univ. of Florida CIS Dept.

|> >>>  e) DEFINITION & IMPLEMENTATION merged.

|>  >>This was a really bad move.  Now you can't define the interface separately
|>  >>and enforce it, and the "*" and "-" stuff is really kludgy, very atypical
|>  >>of Wirth's work.  Even if you accept that merging the def and imp is good,
|>  >>interface details like READONLY really deserve their own keywords.

|>  No, this is a good move.  The maintenance of only 1 file is a big
|>  win.  If you are concerned about the definition being published with
|>  the source, don't worry.  There is a `Browser' module which will
|>  output a definition for a compiled module.  You can then ship the
|>  defintion (sans comments, unless you provide them) with your object
|>  modules.

If both the interface and the implementation are in one file, how do you
tell when only the implementation was changed?  This is very important for
large projects.  Some of the projects that I have been involved with contain
more than a million lines of code.  These projects (done in Ada) would take
several DAYS just to compile.  If the interface to a package was changed,
we would have to go through that horrendous compile cycle whereas if just
the implementation was changed, we only needed to relink.  How does Oberon
handle this?

Ben
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: Fri, 20 Nov 92 13:10:39 GMT

In article <1992Nov19.104407.338@jyu.fi>, sakkinen@jyu.fi (Markku Sakkinen) writes:
> Fortran, I think, has a rule stating that if a formal parameter is
> modified within a subprogram, the corresponding actual parameter must
> not be the same as any other actual parameter in the call.
> Does Modula-2 or Oberon have a similar rule?  (Value parameters need
> not be considered, but constant parameters would if passed by reference.)

I'm not familiar with Fortran but neither Modula-2 nor Oberon have
a rule which forbid to pass the same actual parameter to two or more
parameters, i.e.

   PROCEDURE p(VAR x, y: INTEGER); BEGIN ... END p;
   (* ... *)
   p(i, i);

is legal.

> Of course, those breaches of the rule that cannot be detected at compile
> time could be too expensive to catch at run time.

That's the problem and I still don't see a better solution by
use of constant attributes for parameters.

-- 
_______________________________________________________________________________

Andreas Borchert, University of Ulm, SAI, D-W-7900 Ulm, Germany
Internet: borchert@mathematik.uni-ulm.de
Newsgroups: comp.lang.modula2
Subject: Re: Oberon vs Modula-2 (Re: mail delivery error)
From: news@massey.ac.nz (USENET News System)
Date: Thu, 19 Nov 92 20:29:45 GMT
 <1992Nov16.080647.26783@informatik.uni-ulm.de> <1992Nov17.155855.4413@let.rug.nl> <1992Nov19.104407.338@jyu.fi>
Organization: Massey University

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

Wait until I put on my asbestos suit...

OK

The _only_ correct way of parameter passing is for all
parameters to be constant throughout the execution
of the procedure, they are evaluated when the procedure
is called. It is sometimes convenient to use value
parameters, but it is better to declare a local variable
so the parameter doesn't even _appear_ to be modified.

If you want to return values, use a function procedure.
This implies that a decent laguage must return structured
type. Structure displays would also be useful so that we
can assign results directly to a list of variables.
(E.g. (x, y) := F(u, v, w);)

For example, we might want a string APPEND procedure.
Instead of the traditional
APPEND(S1, S2);
which changes S2 to S2 with S1 appended, you would write
S2 := APPEND(S1, S2);
A good compiler should be able to implement this as though
var parameters were used, but implementation details are
irrelevant for the high level language user.
From: Rick_Sutcliffe@FAITH.TWU.CA ("", Rick Sutcliffe)
Newsgroups: comp.lang.modula2
Subject: FWD>modula-2
Date: 16 Nov 92 16:45:46 GMT
Reply-To: Modula2 List <INFO-M2%UCF1VM.BITNET@uga.cc.uga.edu>
Distribution: world
Organization: Trinity Western University

From TWU_SMTP                 FWD>modula-2
I forward this request on behalf of a colleague.  Please reply to him
directly.

-------

I would like to ask you if you could help with the following
questions related to Modula-2 (if you can, please, just edit my e-mail):
	1) availability of public domain Modula-2 (i.e. ftp site)
	2) availability of real-time scheduler, source code, written
		in Modula-2 (again, an ftp site would help)

	thanks
		frank niscak
		North Island College - Comox Valey

	e-mail:	niscak@nicad3.nic.bc.ca

	phone:	334-5045
From: John.Mcmonagle@f590.n139.z1.fidonet.org (John Mcmonagle)
Newsgroups: comp.lang.modula2
Subject: Linking JPI M2 to MicroSoft C .OBJ
Date: Sun, 15 Nov 92 15:45:58 PDT
Organization: FidoNet node 1:139/590 - PMI BBS, Green Bay WI


Thanks for the correction Mike.  I copied it incorrectly off another computer.



--  
uucp: uunet!m2xenix!puddle!139!590!John.Mcmonagle
Internet: John.Mcmonagle@f590.n139.z1.fidonet.org
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.modula2
Subject: Re: Oberon vs Modula-2
Date: 21 Nov 92 18:03:32 GMT
Organization: Department of Computer Science, University of Manchester
In-reply-to: templ@inf.ethz.ch's message of 21 Nov 92 09:53:07 GMT

In article <1992Nov21.095307.19198@neptune.inf.ethz.ch> templ@inf.ethz.ch (Josef Templ) writes:
   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.

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? 

bevan
Newsgroups: comp.lang.modula2