<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><pre class="" style="background-color: rgb(255, 255, 255);"><br class=""></pre><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">> On Wed Oct 4 22:27:58 CEST 2017 joerg.straube@<a href="http://iaeth.ch" class="">iaeth.ch</a> wrote:</span></font><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">></span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">> > Since integers and integer variables can be assigned to byte variables the</span></font><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class="">> > type inclusion concept makes no sense in Oberon-07. It should be dropped from the appendix.</span></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">></span></font></div><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class="">> I’m open to that point. I liked the idea of inclusion. E.g. what is the type of c in</span></div><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class="">> CONST c = 30; ? Is it BYTE or is INTEGER? </span><span style="white-space: pre-wrap; font-family: monospace;" class="">This was the reason why I let it in, but restricted </span></div><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class="">> it to integer type and adapted rule Assignment 2 accordingly. But feel free.</span><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">></span><br class="Apple-interchange-newline"><br class=""><span style="white-space: pre-wrap;" class="">I would suggest to drop type inclusion from Oberon-07 and its type rules, for the following reasons:</span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class=""><br class=""></span></font><pre class="" style="background-color: rgb(255, 255, 255);"><span style="white-space: pre-wrap;" class="">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 </span><span style="white-space: pre-wrap;" class="">⊇ </span><span style="white-space: pre-wrap;" class="">REAL </span><span style="white-space: pre-wrap;" class="">⊇ </span><span style="white-space: pre-wrap;" class="">LONGINT </span><span style="white-space: pre-wrap;" class="">⊇ </span><span style="white-space: pre-wrap;" class="">INTEGER ⊇ SHORTINT”.</span></pre><pre class="" style="background-color: rgb(255, 255, 255);"><span style="white-space: pre-wrap;" class=""><br class=""></span></pre><pre class="" style="background-color: rgb(255, 255, 255);"><span style="white-space: pre-wrap;" class="">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 <a href="https://www.inf.ethz.ch/personal/wirth/Oberon/Oberon07.pdf" class="">https://www.inf.ethz.ch/personal/wirth/Oberon/Oberon07.pdf</a> and and “Oberon-07 (Oberon At a Glance)” at </span><a href="https://www.inf.ethz.ch/personal/wirth/Oberon/OberonAtAGlance.pdf" style="white-space: pre-wrap;" class="">https://www.inf.ethz.ch/personal/wirth/Oberon/OberonAtAGlance.pdf</a><span style="white-space: pre-wrap;" class="">. </span><span style="white-space: pre-wrap;" class="">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.</span></pre><pre class="" style="background-color: rgb(255, 255, 255);"><span style="white-space: pre-wrap;" class=""><br class=""></span></pre><pre class="" style="background-color: rgb(255, 255, 255);"><span style="white-space: pre-wrap;" class="">3. Oberon-07 also introduced the type BYTE as a subrange of INTEGER (0 .. 255). The intent was to prevent the frequent abuse of </span><span style="white-space: pre-wrap;" class="">module SYSTEM for type conversions using SYSTEM.VAL and the </span><span style="white-space: pre-wrap;" class="">type CHAR for small numbers. S</span><span style="white-space: pre-wrap;" class="">ince the type BYTE in Oberon-07 is defined as a *subrange* </span><span style="white-space: pre-wrap;" class="">of INTEGER with values 0 .. 255, no conversion</span><span style="white-space: pre-wrap;" class=""> </span><span style="white-space: pre-wrap;" class="">functions are needed, i.e. there are no implicit type casts. However, assigning to a variable of type BYTE may</span><span style="white-space: pre-wrap;" class=""> </span><span style="white-space: pre-wrap;" class="">cause overflow.</span><span style="white-space: pre-wrap;" class=""> </span><span style="white-space: pre-wrap;" class="">Typically, arithmetic operations are performed on values of type INTEGER, that is, the compiler</span><span style="white-space: pre-wrap;" class=""> </span><span style="white-space: pre-wrap;" class="">treats variables of type BYTE with form </span><span style="white-space: pre-wrap;" class="">Int in the respective entries for data types (=elements of type ORB.Type in module ORB of the compiler on RISC). </span><span style="white-space: pre-wrap;" class="">Whether we should call *that* feature now "type inclusion” or not, is a semantic question. Technically it is, but </span><span style="white-space: pre-wrap;" class="">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.</span></pre><pre class="" style="background-color: rgb(255, 255, 255);"><span style="white-space: pre-wrap;" class=""><br class=""></span></pre><pre class="" style="background-color: rgb(255, 255, 255);"><span style="white-space: pre-wrap;" class="">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.</span></pre><pre class="" style="background-color: rgb(255, 255, 255);"><span style="white-space: pre-wrap;" class=""><br class=""></span></pre><pre class="" style="background-color: rgb(255, 255, 255);"><span style="white-space: pre-wrap;" class="">My two (California) cents..</span></pre><pre class="" style="background-color: rgb(255, 255, 255);"><span style="white-space: pre-wrap;" class="">-AP</span></pre></div></div></div></body></html>