[Oberon] RE: Oberon digest, Vol 1 #57 - 10 msgs

[Willem Myburgh]

Hi all

On Tue, 27 Aug 2002, Frank van Riet wrote:

> I'm really uncomfortable with trying to hide the size of variables
> i.e.  having a single integer type. I feel that this actually
> detracts from the portability of the code.  In representing numbers
> we have physical representations of abstract entities. We only have
> a finite number of bits available on a given machine. That in itself
> is usually not a problem, the problem arises when we have need to
> port code to a different machine as was pointer out by Patrick. Most
> people are aware of the architecture specific nature of C's
> "int"-type.

You're right, its indeed idealistic to expect a generic integer type in
a language, because of the limitations imposed by processors and
implementations. Nevertheless, just for the interest, in "From Modula to
Oberon" (1988), N. Wirth definitely followed the idea of abstraction:

 "the language must be defined in terms of mathematical, abstract
 concepts without reference to any computing mechanism. Only if a
 language satisfies this criterion, can it be called `higher-level'. No
 syntactic coating whatsoever can earn a language this attribute alone."

This makes the *language* as such portable, but indeed restricts the
portability of the code in the language, as FvR has mentioned.

Wirth again:

 "Limitations imposed by particular implementations do not belong to a
 language definition proper. Examples of such restrictions are the
 maximum values of numbers, rounding and truncation errors in
 arithmetic, and actions taken when a program violates the stated rules.
 It should not be necessary to supplement a language definition with a
 voluminous standards document to cover `unforeseen' cases."

That is why the functions MAX() and MIN() are used in the definition of
the basic numerical types and the SET type, to allow flexibility between
implementations. This indeed makes code hardly portable, when
assumptions are made as to the results of these functions, for example
when it is assumed that a SET may contain 32 values - there are
implementations where a SET may only contain 16 values (or whatever).
(Patrik you're right - SETs should not be a problem in low-level programming)

Wirth also understood the other side of the abstract coin:

 "But neither should a programming language be a mathematical theory
 only. It must be a practical tool." ... "Several features of Oberon are
 superfluous from a purely theoretical point of view. They are
 nevertheless retained for practical reasons, either for programmer's
 convenience or to allow for efficient code generation" ...

He admitted that "Neither the language nor its defining document
reaches the ideal; but Oberon approximates these goals much better than
its predecessors".

So there is room for careful improvement, in the "spirit of Oberon".
(It is happening: the introduction of Active Objects is an
example... :-)

--Willem


-- 
Willem Myburgh
Department of Computer Science
University of Stellenbosch, Private Bag X1, Matieland 7602 South Africa
 Email: myburgh at cs.sun.ac.za        "http://www.cs.sun.ac.za/~myburgh/"
   Tel: +27 (0)21 808 4389 (W)
   Fax: +27 (0)21 808 4416
Mobile: +27 (0)83 415 0416
-----------------------------------------------------------------------