[Oberon] Numbers

[Frank Copeland]

On Mon, Aug 26, 2002 at 10:06:31AM -0400, Douglas G. Danforth wrote:

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

I believe the opposite. I deduce this from the fact that the original
Oberon implementation for the Ceres system included 8-bit SHORTINTs,
16-bit INTEGERs, 32-bit LONGINTs, 32-bit IEEE REALs and 64-bit IEEE
LONGREALs, which happened to precisely match (most of) the basic
numeric types supported by the NS32000-series CPUs chosen for this
project.

If any of Wirth's languages used a conceptual representation of a
number it was Pascal, which had only two numeric types (integer and
real) and supported integer subrange types. Modula-2 expanded the
numeric repertoire to include fixed-length signed integers (SHORTINT,
INTEGER, LONGINT), fixed-length unsigned integers (SHORTCARD, CARDINAL,
LONGCARD) and fixed-length floating-point numbers (REAL, LONGREAL),
while retaining the integer subranges. Modula-2's numeric types
encompassed the basic numeric types supported by most of the CPUs
available at the time (apart from, perhaps, BCD integers).

It is made clear in "From Modula to Oberon" that unsigned integer types
and integer subranges were omitted from Oberon for implementation
rather than conceptual reasons:

  "The basic type CARDINAL had been introduced in Modula in order to
  allow address arithmetic with values from 0 to 216 on 16-bit
  computers. With the prevalence of 32-bit addresses in modern
  processors, the need for unsigned arithmetic has practically
  vanished, and therefore the type CARDINAL has been eliminated. With
  it, the bothersome incompatibilities of operands of types CARDINAL
  and INTEGER have disappeared."

Unfortunately, outside the limited scope of ETH's research projects,
people are using unsigned integers with gay abandon for purposes other
than address arithmetic. This makes writing Oberon programs that are
interoperable with real-world operating systems and data formats
considerably more painful than necessary. The last Oberon program I
wrote involved transforming signed 16-bit values (altitudes) into
unsigned 16-bit values (grayscales), while converting between
big-endian and little-endian representations. Thankfully OOC's I/O
modules handled the *-endian issues for me.

> Do you really want to 'program' or do you want to 'specify' and
> 'solve'.  Ultimately, the later approach would be my choice.

I want to be able to do both, depending on the requirements of the
problem domain I am working in. In my view, compared to Modula-2,
Oberon represents a regression as far as numeric processing is
concerned.

Frank
-- 
Home Page: <URL:http://thingy.apana.org.au/~fjc/> 
Not the Scientology Home Page: <URL:http://xenu.apana.org.au/ntshp/>