[Oberon] Clarifying type compatibility in Oberon-07

[Andreas Pirklbauer]

> On Wed Oct 4 22:27:58 CEST 2017 joerg.straube at iaeth.ch <http://iaeth.ch/> wrote:
>
> > Since integers and integer variables can be assigned to byte variables the
> > type inclusion concept makes no sense in Oberon-07. It should be dropped from the appendix.
>
> I’m open to that point. I liked the idea of inclusion. E.g. what is the type of c in
> CONST c = 30; ? Is it BYTE or is INTEGER? This was the reason why I let it in, but restricted 
> it to integer type and adapted rule Assignment 2 accordingly. But feel free.
>

I would suggest to drop type inclusion from Oberon-07 and its type rules, for the following reasons:

1. In Original Oberon and Oberon-2, the concept of “type inclusion” was defined as follows (see their respective language reports): “The types SHORTINT, INTEGER and LONGING are integer types, the types REAL and LONGREAL are real types, and together they are called numeric types. They form a hierarchy; the larger type includes (the values of) the smaller type: LONGREAL ⊇ REAL ⊇ LONGINT ⊇ INTEGER ⊇ SHORTINT”.

2. In Oberon-07 the concept of "type inclusion" (in the above form) has been suppressed, as outline in the documents “Differences between Revised Oberon and Oberon at https://www.inf.ethz.ch/personal/wirth/Oberon/Oberon07.pdf <https://www.inf.ethz.ch/personal/wirth/Oberon/Oberon07.pdf> and and “Oberon-07 (Oberon At a Glance)” at https://www.inf.ethz.ch/personal/wirth/Oberon/OberonAtAGlance.pdf <https://www.inf.ethz.ch/personal/wirth/Oberon/OberonAtAGlance.pdf>. One of the reason for this decision was that type inclusion was considered a bad idea to start with. It requires the compiler to insert hidden type conversions (type casts), which may not always be obvious to the programmer or reader of a piece of code. Hidden mechanisms generally are not in the spirit of Oberon. In Oberon-07 *all* type casts must be explicitly programmed.

3. Oberon-07 also introduced the type BYTE as a subrange of INTEGER (0 ... 255). The intent was to prevent the frequent abuse of module SYSTEM for type conversions using SYSTEM.VAL and the type CHAR for small numbers. Since the type BYTE in Oberon-07 is defined as a *subrange* of INTEGER with values 0 .. 255, no conversion functions are needed, i.e. there are no implicit type casts. However, assigning to a variable of type BYTE may cause overflow. Typically, arithmetic operations are performed on values of type INTEGER, that is, the compiler treats variables of type BYTE with form Int in the respective entries for data types (=elements of type ORB.Type in module ORB of the compiler on RISC). Whether we should call *that* feature now "type inclusion” or not, is a semantic question. Technically it is, but I would not - it only creates confusion with the older definition used in Original Oberon and Oberon-2 (compatibility between integers and reals) which actually requires the insertion of type conversion functions by the compiler.

I would therefore plead to simply drop type inclusion altogether from the language (fully knowing that BYTE kind of represents an exception, but not really). It would also bring Oberon-07 bring in line with how this is handled in modern languages such as Swift, where *all* type conversions must be explicitly programmed, no matter what.

My two (California) cents..
-AP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20171005/47308096/attachment.html>