[Oberon] Numbers

[Patrik Reali]

Hallo again!

dear Frank, I didn't mean to be so negative about your comments. I think
there is need for unsigned integers: one rule we always followed is to avoid
redundancy in the language, and unsigned integer are not, nor can be without
great difficulty, be achieved with the language as is.

> I have a fair amount of experience in compilers and languages.
> I am well aware that integer type interoperability conjures up
> images of hell fit to be included in something by Dante :)

It does. At least Dante has some funny quotes, and a good guide to follow! A
change like you propose is quite an undertaking: first of all it means a new
release, because new symbol and object file format are needed to represent
the new types, and then the implementation can get quite complex.

> 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 agree, this is a simplification.

> Patrik I have to disagree with your point on values versus flags. A stack
> pointer
> (for instance) is an unsigned value the size of a machine word -period.

You're right. I didn't donsider this case.

> The other
> integer types are still visible to programmer, otherwise were heading back
> to B
> (or is that BCPL?) ? Please correct if I'm wrong.

Well Lisp has no types at all.... :-) (But is also quite old)

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

This would be indeed nice, but have negative consequences on the language
portability: picture yourself addind a size test every time you import a
file that contains integers, because you're running on a 32-bit machine and
the file may have been written on a 64-bit one. This would make data that is
legal on one machine illegal on another one. Sometimes beauty and usability
don't go hand in hand.... (but this is rather the exception).


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

But one of the goals of Oberon (as inherited from modula), is to be able to
implement systems with the language.

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

This would be a solution indeed. We already though along those lines when
discussing the introduction of a single integer type, but then dropped it
(the cost of the implementation vs. the benefits was to small)

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

But low-level programming is not portable across platforms, so this should
not disturb too much. I just know of a few cases where this is a problem, in
the network drivers.


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

You do. The only problem is, my resources are extremely limited at the
moment, and it's frustrating to see so many good ideas being wasted because
I turn out to be a bottleneck.

Just keep in mind that I cannot and won't change something in the language,
only make additions.


-Patrik