mail delivery error 
Author Message
 mail delivery error

---------------------------- Forwarded with Changes ---------------------------

Date: 11/9/92 9:54AM
To: thutt at casi
Subject: mail delivery error
-------------------------------------------------------------------------------
-=> (again) Quoting Roland Frederic to All <=-

RF> Hi! I'm new here and I recently read a text file about Modula-2 and
RF> Oberon. For now I program in Turbo Pascal and since I eard that all
RF> these languages came from Niclaus (sic, it is actually Niklaus) Wirth
RF> I wish to have a few enlightment about difference between these languages.

   Since someone has already answered the Modula-2 side of the question, I will
   answer the Oberon side.

   Oberon (named for the moon of Uranus) was developed by N. Wirth and J.
   Gutknecth of ETH.  The design goal was one of simplicty, and that is
   reflected in the language and the operating system.

   Oberon removes all of the extraneous features of Modula-2, cleans up the
   language, and adds a few new features to allow for more type checked variant
   records (and object oriented programming style).

   Each of these things will be tackled briefly (after all, I have to earn a
   living).

   1) Removal of superfluous items:
      a) Enumerations:  They do not add enough expressiveness to a program
      to warrant the added complexity in the compiler.  For the most part,
      if you are using modules in a good fashion, you can use constants in
      the place of enuerations.  The only drawback to this is that of
      type-checking.
      b) Nested modules:  Discovered to be hardly used, and thus removed c)
      generic SET OF: Since there is no enumeration, what are you to make a
      set from?  The SET type is now equivalent to the M-2 BITSET. It is of
      an implementation dependant size (usually at least 32 bits). d) FOR
      statement removed in Oberon.  It is reinstated in Oberon-2.
      e) DEFINITION & IMPLEMENTATION merged.  Exported identifiers are
      marked with a *.  Read-only exported variables are marked with a -.
      Let us hope they make a read-only VAR parameter, which would be
      useful for exported procedures that take a VAR parm for efficiency.
      The programmer using the procedure would be guaranteed that the
      parameter is not modified!

   Some other items have also been removed, but these are the biggies.

   2) Cleans up the language
      a) concept of mathematical inclusion. SHORTINT (subset of) INTEGER
      (subset of) LONGINT (subset of) REAL (subset of) LONGREAL.  Thus, you
      can assign any smaller type to any larger type without an error.  The
      SHORT and LONG procedures allow you to convert from a longer type to
      a shorter type, and the ENTIER allows a real to integer conversion.
      b) All language constructs still fully bracketed.  No dangling ELSE a
      la Pascal.
      c) If a statement does not match any item in a CASE or WITH, _and_ no
      ELSE cluase is specified, the program will abort. (Not a language
      clean up, but it is clearly specified)

   3) New items
      a) Type extension, testing, guard
      b) New form of WITH
      c) FOR construct reintroduced
      d) Type-bound procedures (Oberon-2) (also called methods or member
      functions)

You can obtain an implementation of Oberon for the RS6000, SPARCstation,
DEC3100, MacII or MSDOS (requires 386) from neptune.ethz.ch
(129.132.101.33).  You can also get the Oberon documentation (langauge
definition, et al) from this site.  Check out the subdirectory /Oberon


Championing worldwide usage of Oberon-2!



Fri, 28 Apr 1995 23:22:39 GMT  
 mail delivery error

Quote:

>   1) Removal of superfluous items:
>      a) Enumerations:  They do not add enough expressiveness to a program
>      to warrant the added complexity in the compiler.  For the most part,
>      if you are using modules in a good fashion, you can use constants in
>      the place of enuerations.  The only drawback to this is that of
>      type-checking.

I wouldn't classify enumerations as "superfluous", their removal is a real
loss.  But I think the real reason they went was because they are so difficult
to type-extend.  Type-extension is Oberon's "thing", and it would be most
difficult to set up a mechanism wereby various enumerations were derived from
previously-defined enumerations, where certain identifiers are valid for all,
but not all identifiers are.

Quote:
>      b) Nested modules:  Discovered to be hardly used, and thus removed

I used 'em, but it makes more sense to make modules the unit of compilation,
and not worry about nesting them.  A useful simplification.

Quote:
>      c) generic SET OF: Since there is no enumeration, what are you to make
>      a set from?  The SET type is now equivalent to the M-2 BITSET. It is of
>      an implementation dependant size (usually at least 32 bits).

This was Wirth not going far enough.  Without enumerations, sets really have
little utility or expressiveness over bit-pushing operators like C's.  SETS
could have been axed in favor of a slight extension of the INTEGER type.

Quote:
>      d) FOR statement removed in Oberon.  It is reinstated in Oberon-2.

Wirth discovered that counting loops really are a primitive construct.

Quote:
>      e) DEFINITION & IMPLEMENTATION merged.  Exported identifiers are
>      marked with a *.  Read-only exported variables are marked with a -.
>      Let us hope they make a read-only VAR parameter, which would be
>      useful for exported procedures that take a VAR parm for efficiency.
>      The programmer using the procedure would be guaranteed that the
>      parameter is not modified!

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.

Just about the best language money can buy, though. All it needs is a good
exception-handling mechanism to be ready to take on all comers.


-
Liberty is not the freedom to do whatever we want,
it is the freedom to do whatever we are able.



Sun, 30 Apr 1995 01:51:08 GMT  
 mail delivery error

Quote:


>> ...
>I wouldn't classify enumerations as "superfluous", their removal is a real
>loss.  But I think the real reason they went was because they are so difficult
>to type-extend.  Type-extension is Oberon's "thing", and it would be most
>difficult to set up a mechanism wereby various enumerations were derived from
>previously-defined enumerations, where certain identifiers are valid for all,
>but not all identifiers are.

That has obviously been the main reason for eliminating enumerations.
And even this rationale is very weak.  Only record types can be extended
in Oberon, not atomic types nor arrays.

Quote:
> ...
>>      c) generic SET OF: Since there is no enumeration, what are you to make
>>      a set from?  The SET type is now equivalent to the M-2 BITSET. It is of
>>      an implementation dependant size (usually at least 32 bits).

>This was Wirth not going far enough.  Without enumerations, sets really have
>little utility or expressiveness over bit-pushing operators like C's.  SETS
>could have been axed in favor of a slight extension of the INTEGER type.

I don't agree, especially since C has not got bit arrays.
But set types have always been sadly crippled in
Wirth's languages:  Pascal implementers are not required to support
even the the full CHAR type as the base type for SET OF CHAR,
not to speak of true SET OF INTEGER.  Fully-fledged set types could often
be useful abstractions in programming.

Quote:
>> ...
>>      e) DEFINITION & IMPLEMENTATION merged.  Exported identifiers are
>>      marked with a *.  Read-only exported variables are marked with a -.
>>      Let us hope they make a read-only VAR parameter, which would be
>>      useful for exported procedures that take a VAR parm for efficiency.
>>      The programmer using the procedure would be guaranteed that the
>>      parameter is not modified!

I have read somewhere that the parameter modes were variable vs. constant
in an early version of Pascal.  That would have been much better
than the current by-value vs. by-reference distinction (which should be left
as an implementation issue)!

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

Field-width denoters in the calls of the READ and WRITE quasi-procedures
of Pascal spring to mind as a worse syntactic kludge, but it is
nevertheless atypical.

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


Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------



Sun, 30 Apr 1995 18:24:09 GMT  
 mail delivery error
Quote:



>>> ...
>>I wouldn't classify enumerations as "superfluous", their removal is a real
>>loss.  But I think the real reason they went was because they are so difficult
>>to type-extend.  Type-extension is Oberon's "thing", and it would be most
>>difficult to set up a mechanism wereby various enumerations were derived from
>>previously-defined enumerations, where certain identifiers are valid for all,
>>but not all identifiers are.

>That has obviously been the main reason for eliminating enumerations.
>And even this rationale is very weak.  Only record types can be extended
>in Oberon, not atomic types nor arrays.

Enumerations are often used as the discriminent in variant records.  In Oberon
you declare different records that are extensions of a common record.  You also
delcare a different pointer type to each one and the type name of the pointer
takes the place of the enumeration so you get the effect of enumerations, but
it's extendable over module boundries.  Pretty neat!

+-----------------------------------+----------------------------------------+
|                                   |                                        |
| Larry Maturo                      | Opinions expressed herein must be      |
| Tactical Simulation Division      | yours, neither I nor my employer have  |
| Applied Research Laboratories     | any.                                   |
| University of Texas at Austin     |                                        |
| P.O. Box 8029                     +----------------------------------------+
| Austin, Texas 78713-8029          |                                        |
|                                   | When you're as great as I am it's hard |

|                                   | others fail.                           |
+-----------------------------------+----------------------------------------+



Sun, 30 Apr 1995 21:49:40 GMT  
 mail delivery error

      Oberon removes all of the extraneous features of Modula-2, cleans up the
      language
      [deleted]

      1) Removal of superfluous items:
         [deleted]
         The SET type is now equivalent to the M-2 BITSET. It is of
         an implementation dependant size (usually at least 32 bits).

If you ask me (and of course you didn't :-), SET should have been
dropped.  What is the point of having a BITSET (and why isn't it
called that if that is what it is?) with an implementation defined
size?  Why is this any better than having a MODULE based around BIT
... etc. which achieves the same effect?  (Also why is there no
operation to directly set a bit?)  If your wondering what the
difference is in the end: nothing much as far as functionallity goes,
the difference is by using a modules, superfluous items is kept out of
the syntax.

bevan



Mon, 01 May 1995 03:40:23 GMT  
 mail delivery error

   [ much that I agree with ]

   >      e) DEFINITION & IMPLEMENTATION merged.  Exported identifiers are
   >      marked with a *.  Read-only exported variables are marked with a -.
   >      Let us hope they make a read-only VAR parameter, which would be
   >      useful for exported procedures that take a VAR parm for efficiency.
   >      The programmer using the procedure would be guaranteed that the
   >      parameter is not modified!

   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.

You could, of course, argue that the def/imp model is a "bad move"
because it forces one interface on a piece of code.  There is nothing
stopping me using an implementation for more than one purpose (e.g. an
avl tree to implement a set or a map) by having two interfaces to it
(a la signatures/structures in ML).  Personally I'm ambivalent.

   Just about the best language money can buy, though. All it needs is a good
   exception-handling mechanism to be ready to take on all comers.

Hm, seems to be a bit of deja vu here :-)  Did you see/reply to my
last set of questions about your view of exception handling.  I didn't
see any folloup.

bevan



Mon, 01 May 1995 20:29:29 GMT  
 mail delivery error

Quote:



> >> ...
> >I wouldn't classify enumerations as "superfluous", their removal is a real
> >loss.  But I think the real reason they went was because they are so difficult
> >to type-extend.  Type-extension is Oberon's "thing", and it would be most
> >difficult to set up a mechanism wereby various enumerations were derived from
> >previously-defined enumerations, where certain identifiers are valid for all,
> >but not all identifiers are.

> That has obviously been the main reason for eliminating enumerations.
> And even this rationale is very weak.  Only record types can be extended
> in Oberon, not atomic types nor arrays.

Extending atomic types or arrays is completely different from extending
records which usually represent abstractions. Records are sufficient
and the implementation of record extensions is straightforward and efficient.

The main problem is to assure extensibility of existing software. This
is done in Oberon by extending given abstractions to your problem which
allows your new data types to be processed by software written earlier.

In some cases enumeration types tend to prohibit extensibility if they
are exported. Nevertheless, it would be possible to include them
in Oberon in Modula-2 manner without great trouble.

Possible extensions of arrays and atomic types would like other
features (e.g. exceptions or whatever) make life more difficult: for
the language designer, the compiler constructor and, of course, the
programmer which would have to read a 600-pages Modula-Standard style
manual. Don't forget that Oberon still needs less than 20 pages of
language description.

As long as it is possible to formulate problems in a elegant manner in
Oberon we don't need to blow up the language. Try to view your libraries
itself as extensions of the language and you get all what you need:
extensible arithmetic data types, exceptions (which need coroutines
of course, but at least my implementation has them) or whatever.

Don't forget, Wirth's primary design goal was: "Make it as simple as
possible. But not simpler."

Quote:
> >>      c) generic SET OF: Since there is no enumeration, what are you to make
> >>      a set from?  The SET type is now equivalent to the M-2 BITSET. It is of
> >>      an implementation dependant size (usually at least 32 bits).

> >This was Wirth not going far enough.  Without enumerations, sets really have
> >little utility or expressiveness over bit-pushing operators like C's.  SETS
> >could have been axed in favor of a slight extension of the INTEGER type.

> I don't agree, especially since C has not got bit arrays.
> But set types have always been sadly crippled in
> Wirth's languages:  Pascal implementers are not required to support
> even the the full CHAR type as the base type for SET OF CHAR,
> not to speak of true SET OF INTEGER.  Fully-fledged set types could often
> be useful abstractions in programming.

Wirth's aim was always to avoid putting algorithms into the language
which could be expressed by the language itself. Having a basic set type,
you are able to build up arbitrary set types which work efficiently.

Quote:
> >>      e) DEFINITION & IMPLEMENTATION merged.  Exported identifiers are
> >>      marked with a *.  Read-only exported variables are marked with a -.
> >>      Let us hope they make a read-only VAR parameter, which would be
> >>      useful for exported procedures that take a VAR parm for efficiency.
> >>      The programmer using the procedure would be guaranteed that the
> >>      parameter is not modified!

VAR-parameters which are readonly for efficiency purposes doesn't make
much sense because this is a problem of code optimization. Requests
like this could be easily extended to the horrible register declarations
of C!

I agree with all people which prefer the separation of DEFINITION and
MODULE. The first version of Oberon as published in Software Practice
and Experience was still separated and I still prefer this version
in comparison to all later versions (with the exception of some
syntactical clean ups).

Quote:
> I have read somewhere that the parameter modes were variable vs. constant
> in an early version of Pascal.  That would have been much better
> than the current by-value vs. by-reference distinction (which should be left
> as an implementation issue)!

The choice between by-value and by-reference as an implementation issue?
Sounds not reasonable -- probably I've missed your point.

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

> Field-width denoters in the calls of the READ and WRITE quasi-procedures
> of Pascal spring to mind as a worse syntactic kludge, but it is
> nevertheless atypical.

I agree. Programs should be readable but not cryptical.

--
_______________________________________________________________________________

Andreas Borchert, University of Ulm, SAI, D-W-7900 Ulm, Germany



Tue, 02 May 1995 18:01:54 GMT  
 mail delivery error

Quote:

>> ...
>>That has obviously been the main reason for eliminating enumerations.
>>And even this rationale is very weak.  Only record types can be extended
>>in Oberon, not atomic types nor arrays.

>Enumerations are often used as the discriminent in variant records.  In Oberon
>you declare different records that are extensions of a common record.  You also
>delcare a different pointer type to each one and the type name of the pointer
>takes the place of the enumeration so you get the effect of enumerations, but
>it's extendable over module boundries.  Pretty neat!

That's only one of the many useful purposes of enumerations!
Furthermore, Oberon's type extensions cannot do all the things
that are possible with tagged variant records (and vice versa).
With variant records, you can change the variant of the object itself.
With type extensions, you can only make a pointer point at an object
of another related type:  that does not affect the original object
nor any other pointers to it.

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


Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------



Tue, 02 May 1995 16:23:28 GMT  
 mail delivery error

Quote:

> >> But set types have always been sadly crippled in
> >> Wirth's languages:  Pascal implementers are not required to support
> >> even the the full CHAR type as the base type for SET OF CHAR,
> >> not to speak of true SET OF INTEGER.  Fully-fledged set types could often
> >> be useful abstractions in programming.

> >Wirth's aim was always to avoid putting algorithms into the language
> >which could be expressed by the language itself. Having a basic set type,
> >you are able to build up arbitrary set types which work efficiently.

> These extremely restricted set types could well be replaced by
> PACKED ARRAY [ ... ] OF BOOLEAN.  It's the set types with large
> base types that are difficult and tedious for programmers to write
> themselves.  Imagine that arrays were restricted to base types
> of cardinality no greater than 128, and you would have to build up
> larger arrays yourself.

To prove the easiness of large set types in Oberon I've attached my
Sets module which accepts arbitrary ARRAY OF SETs.

- Show quoted text -

Quote:
> >> I have read somewhere that the parameter modes were variable vs. constant
> >> in an early version of Pascal.  That would have been much better
> >> than the current by-value vs. by-reference distinction (which should be left
> >> as an implementation issue)!

> >The choice between by-value and by-reference as an implementation issue?
> >Sounds not reasonable -- probably I've missed your point.

> Let me elaborate.  The important conceptual dichotomy in parameters
> is whether the called procedure can modify the actual parameter
> (in the caller's context) or not.  In the former case (variable)
> it is necessary to pass a reference to the actual parameter,
> or do copy in - copy out.  In the latter case (constant), the parameter
> can be passed either by reference or by value,
> without any difference in the semantics.

> Value parameters as in Algol 60, Pascal, Modula-2, etc. bundle
> the choices by not allowing constant parameters to be passed
> by reference.  The gain from this approach is that the programmer
> automatically gets a copy that can be modified without affecting
> the actual parameter.  It was probably quite nice in the Algol 60 days,
> when variables were mostly single integers or reals (and the other
> alternative was the formidable call-by-name).

> The loss is that the copy is done even when
> it is not needed, and with large parameter objects it's a big loss
> (imagine recursive calls with a 1000 x 1000 array parameter).
> It seems to be common practice that programmers declare very
> large parameters as VAR even in cases where they should absolutely
> not be modified -- only to avoid the performance penalty.

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.

Your point (hopefully I understand now your point :-) is that this
decision can be eased for the compiler by replacing call-by-value by
passing of readonly parameters. While this is not really necessary
to achieve the efficiency goal, I believe it's a worthy feature because
it would help to make the code more readable.

And now the promised attachment. It's still in early Oberon style,
i.e. separated DEFINITION and MODULE.

#!/bin/sh
# This is a shell archive (produced by shar 3.49)
# To extract the files from this archive, save it to a file, remove
# everything above the "!/bin/sh" line above, and type "sh file_name".
#

# Source directory /export/home/borchert/tmp/48
#
# existing files will NOT be overwritten unless -c is specified
#
# This shar contains:
# length  mode       name
# ------ ---------- ------------------------------------------
#   3205 -r--r--r-- Sets.3
#   1337 -rw-rw-r-- Sets.od
#   4661 -rw-rw-r-- Sets.om
#
# ============= Sets.3 ==============
if test -f 'Sets.3' -a X"$1" != X"-c"; then
        echo 'x - skipping Sets.3 (File already exists)'
else
echo 'x - extracting Sets.3 (Text)'
sed 's/^X//' << 'SHAR_EOF' > 'Sets.3' &&
.\" --------------------------------------
.\" Oberon System Documentation   AFB 8/90
.\" (c) University of Ulm, SAI, D-7900 Ulm
.\" --------------------------------------
.de Pg
.nf
.ie t \{\
.       sp 0.3v
.       ps 9
.       ft CW
.\}
.el .sp 1v
..
.de Pe
.ie t \{\
.       ps
.       ft P
.       sp 0.3v
.\}
.el .sp 1v
.fi
..
.TH Sets 3 "Oberon System"
.SH NAME
Sets \- operations for sets of arbitrary length
.SH SYNOPSIS
.Pg
CONST setsize = MAX(SET) + 1;
.sp 0.7
TYPE CharSet = ARRAY ORD(MAX(CHAR)) DIV setsize OF SET;
.sp 0.7
VAR lengthError: Events.EventType;
.sp 0.7
PROCEDURE InitSet(VAR set: ARRAY OF SET);
.sp 0.3
PROCEDURE Complement(VAR set: ARRAY OF SET);
.sp 0.3
PROCEDURE Union(set1, set2: ARRAY OF SET; VAR result: ARRAY OF SET);
PROCEDURE Difference(set1, set2: ARRAY OF SET; VAR result: ARRAY OF SET);
PROCEDURE Intersection(set1, set2: ARRAY OF SET; VAR result: ARRAY OF SET);
PROCEDURE SymDifference(set1, set2: ARRAY OF SET; VAR result: ARRAY OF SET);
.sp 0.3
PROCEDURE In(VAR set: ARRAY OF SET; i: LONGINT) : BOOLEAN;
PROCEDURE CharIn(VAR charset: CharSet; ch: CHAR) : BOOLEAN;
PROCEDURE Equal(set1, set2: ARRAY OF SET) : BOOLEAN;
.sp 0.3
PROCEDURE Incl(VAR set: ARRAY OF SET; i: LONGINT);
PROCEDURE Excl(VAR set: ARRAY OF SET; i: LONGINT);
PROCEDURE InclChar(VAR charset: CharSet; ch: CHAR);
PROCEDURE ExclChar(VAR charset: CharSet; ch: CHAR);
.sp 0.3
PROCEDURE Subset(set1, set2: ARRAY OF SET) : BOOLEAN;
PROCEDURE Card(set: ARRAY OF SET) : INTEGER;
.Pe
.SH DESCRIPTION
.I Sets
implements set operations for character sets and
sets of arbitrary length.
.I setsize
defines the number of bits per
.B SET
type.
.I CharSet
is an array of
.B SET
sufficient for characters.
.I InitSet
initializes
.I set
to the empty set.
.PP
Following set operators are implemented:
.sp
.TS
l l.
set operator    set operation
_
unary \fB-\fP   \fIComplement\fP
\fB+\fP \fIUnion\fP
\fB-\fP \fIDifference\fP
\fB*\fP \fIIntersection\fP
\fB/\fP \fISymDifference\fP
\fBIN\fP        \fIIn\fP and \fICharIn\fP
\fB=\fP \fIEqual\fP
\fBINCL\fP      \fIIncl\fP and \fIInclChar\fP
\fBEXCL\fP      \fIExcl\fP and \fIExclChar\fP
.TE
.PP
\fISubset\fP returns \fBTRUE\fP iff
\fIset1\fP is contained in \fIset2\fP.
\fICard\fP returns the cardinality
(number of elements) of \fIset\fP.
.SH DIAGNOSTICS
\fISets\fP
raises \fIlengthError\fP with priority \fIPriorities.assertions\fP
if the length of \fIresult\fP is less than
the length of \fIset1\fP or \fIset2\fP.
.SH "SEE ALSO"
.TS
lfI l.
Assertions(3)   error handling for length errors
.TE
.\" ---------------------------------------------------------------------------
.\" $Id: Sets.3,v 1.5 91/11/25 09:15:53 borchert Exp $
.\" ---------------------------------------------------------------------------
.\" $Log:  Sets.3,v $
.\" Revision 1.5  91/11/25  09:15:53  borchert
.\" lengthError is now handled by Assertions
.\"
.\" Revision 1.4  1991/11/12  08:43:40  borchert
.\" Events.EventNumber replaced by Events.EventType
.\"
.\" Revision 1.3  1991/06/21  15:32:34  borchert
.\" minor fix
.\"
.\" Revision 1.2  91/06/18  13:57:08  borchert
.\" new operators added
.\"
.\" Revision 1.1  90/08/31  17:02:19  borchert
.\" Initial revision
.\"
.\" ---------------------------------------------------------------------------
SHAR_EOF
chmod 0444 Sets.3 ||
echo 'restore of Sets.3 failed'
Wc_c="`wc -c < 'Sets.3'`"
test 3205 -eq "$Wc_c" ||
        echo 'Sets.3: original size 3205, current size' "$Wc_c"
fi
# ============= Sets.od ==============
if test -f 'Sets.od' -a X"$1" != X"-c"; then
        echo 'x - skipping Sets.od (File already exists)'
else
echo 'x - extracting Sets.od (Text)'
sed 's/^X//' << 'SHAR_EOF' > 'Sets.od' &&
(* Oberon Library      -  UNIX System V  -      AFB 9/89 *)
(* (c) University of Ulm, Sektion Informatik, D-7900 Ulm *)
X
DEFINITION Sets;
X
X   IMPORT Events;
X
X   CONST
X      setsize = MAX(SET) + 1;
X
X   TYPE
X      CharSet = ARRAY ORD(MAX(CHAR)) DIV setsize OF SET;
X
X   VAR
X      lengthError: Events.EventType;
X        (* raised with Priorites.assertions if the length of
X           the result is less than its parameters
X        *)
X
X   PROCEDURE InitSet(VAR set: ARRAY OF SET);
X
X   PROCEDURE Complement(VAR set: ARRAY OF SET);
X
X   PROCEDURE In(VAR set: ARRAY OF SET; i: LONGINT) : BOOLEAN;
X
X   PROCEDURE Incl(VAR set: ARRAY OF SET; i: LONGINT);
X   PROCEDURE Excl(VAR set: ARRAY OF SET; i: LONGINT);
X
X   PROCEDURE CharIn(VAR charset: CharSet; ch: CHAR) : BOOLEAN;
X
X   PROCEDURE InclChar(VAR charset: CharSet; ch: CHAR);
X   PROCEDURE ExclChar(VAR charset: CharSet; ch: CHAR);
X
X   PROCEDURE Intersection(set1, set2: ARRAY OF SET; VAR result: ARRAY OF SET);
X   PROCEDURE SymDifference(set1, set2: ARRAY OF SET; VAR result: ARRAY OF SET);
X   PROCEDURE Union(set1, set2: ARRAY OF SET; VAR result: ARRAY OF SET);
X   PROCEDURE Difference(set1, set2: ARRAY OF SET; VAR result: ARRAY OF SET);
X
X   PROCEDURE Equal(set1, set2: ARRAY OF SET) : BOOLEAN;
X   PROCEDURE Subset(set1, set2: ARRAY OF SET) : BOOLEAN;
X
X   PROCEDURE Card(set: ARRAY OF SET) : INTEGER;
X
END Sets.
SHAR_EOF
chmod 0664 Sets.od ||
echo 'restore of Sets.od failed'
Wc_c="`wc -c < 'Sets.od'`"
test 1337 -eq "$Wc_c" ||
        echo 'Sets.od: original size 1337, current size' "$Wc_c"
fi
# ============= Sets.om ==============
if test -f 'Sets.om' -a X"$1" != X"-c"; then
        echo 'x - skipping Sets.om (File already exists)'
else
echo 'x - extracting Sets.om (Text)'
sed 's/^X//' << 'SHAR_EOF' > 'Sets.om' &&
(* Oberon Library      -  UNIX System V  -      AFB 9/89 *)
(* (c) University of Ulm, Sektion Informatik, D-7900 Ulm *)
X ...

read more »



Fri, 05 May 1995 16:06:47 GMT  
 mail delivery error


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

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

  *  wonder everyday    *    nothing in particular    *    all is special  *



Sat, 06 May 1995 02:35:02 GMT  
 mail delivery error

Quote:



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

        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}

        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}

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

--

"You bloated sack of protoplasm!" - Ren



Sat, 06 May 1995 06:18:11 GMT  
 
 [ 37 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. Mail delivery errors

2. ANN: FREEWARE SMTP mail delivery agent for Clarion

3. (Fwd) Mail Delivery Failure.

4. Fwd: Mail delivery failed: returning message to sender

5. Mail Delivery Status

6. Mail Delivery Status

7. Mail Delivery Status

8. Mail Delivery Status

9. Mail Delivery Status

10. [Mailer-Daemon@ignoramus.co.uk: Mail delivery failed: returning message to sender]

11. [Fwd: Mail delivery failed: returning message to sender]

12. Mail delivery failed: returning message to sender

 

 
Powered by phpBB® Forum Software