[Oberon] Numbers

[Willem Myburgh]

Hallo all (especially Frank :)

On Mon, 26 Aug 2002, Douglas G. Danforth wrote:

> Frank van Riet wrote:
> >
> > Hi Patrik, Paul, Greg
> >
> > Thanks very much for your comments.
> ...
> > If you have a look at my original submission you'll note that I did
> > raise this issue, as well as a simple solution. Simply don't allow
> > interoperability between signed and unsigned variables. This makes the
> > impact on the compiler negligable.  This has the additional benefit of
> > forcing to programmer to think about the range of the variables.
>
> I believe Dr. Wirth was attempting to move in the other direction,
> away from implementation issues and toward a conceptual representation
> of a number.  I deduce this from the fact that the term REAL is used
> rather than float.  A floating point representation of a real number
> is a more accurate description of what computers actually do, however,
> to focus on this aspect diverts ones thinking away from the usual
> task at hand of determining the value of an expression.

I agree that implementation issues should not affect language elements,
and thus also the supported data types. If one thinks in a specific
language, it should not be necessary to think how it is translated to
another one (in our case, a machine language and concrete
representations). Hence, for integers, a language should only have one
generic INTEGER type, without any restrictions on the values its
variables may contain. When one only needs natural numbers (i.e.
unsigned integers) in some context, a language may allow sub-typing, for
example:

 TYPE
 	UINT32: INTEGER (0 .. 0FFFFFFFFH);
 VAR
   myNaturalNumberVariable: INTEGER (0 .. INFINITY);
	my32BitUnsignedInt: UINT32;

The problem of a compiler should be to represent these values in an
approriate way on the target platform. Besides the point, this may sound
as a bit idealistic, because where is a processor that could handle
infinitely many integer values?  IA32 Architecture supports at least a
range of -2147483648 .. +4294967295 for integers, while Native Oberon on
IA32, only supports a range of -2147483648 .. +2147483647.

The Oberon language is inherently portable as it is (?), and should
*not* be adapted with unnecessary data types, which stem from
implementation specific needs...

I think the problem of Frank, regarding unsigned integers, is that of
low-level systems programmers (Those who don't mind making their hands
dirty with assembler, C, etc). Systems programmers have to think in
terms of representations in memory, which violates the use of a language
as I indicated above. During the last decade (and a few years) of the
existence of Oberon, OBERON has proven itself as an outstanding secure
language, a desired property of a language for reliable systems
programming. And from the beginning of its implementation, a MODULE
SYSTEM existed providing that gap between platform specific issues, and
portable language elements.

Hence, the SYSTEM module is the gateway to be followed by systems
programmers, to get to a specific processor.  As a systems programmer
myself, my opinion is that the SYSTEM module could be carefully extended
to incorporate some of the concerns mentioned by Frank. In fact, the
SYSTEM module definitely lack some usefull processor specific types and
functions: I don't see any harm to provide a SYSTEM.UINT32, a
SYSTEM.UINT16, and a SYSTEM.UINT8.  (SYSTEM.BYTE, as far as I know, has
an unsigned 8 bit representation on IA32.) This would definitely reduce
the "SYSTEM.VAL"-cluttered code and their erroneous absence (which we
found happening numerous times in low level programming projects) in
SYSTEM.PORTIN and SYSTEM.PORTOUT "procedure calls".  In addition,
unsigned operations could be supported, such as SYSTEM.ABOVE and
SYSTEM.BELOW for comparisons.

(Besides the point, the use of SETS for low-level programming is not good,
because Oberon compilers are representing SETS differently on different
platforms.)

Hopefully this provides some constructive critique, not on the Oberon language,
but on the low level support, which are provided by Oberon compilers,
and therefor indeed something Patrik should consider.

Its great to be associated with a language the calibre of OBERON!

Cheers
--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
-----------------------------------------------------------------------