<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
        {mso-style-priority:99;
        mso-style-link:"Nur Text Zchn";
        margin:0cm;
        margin-bottom:.0001pt;
        font-size:9.0pt;
        font-family:Consolas;
        mso-fareast-language:EN-US;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0cm;
        margin-right:0cm;
        margin-bottom:0cm;
        margin-left:36.0pt;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        mso-fareast-language:EN-US;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-margin-top-alt:auto;
        margin-right:0cm;
        mso-margin-bottom-alt:auto;
        margin-left:0cm;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.NurTextZchn
        {mso-style-name:"Nur Text Zchn";
        mso-style-priority:99;
        mso-style-link:"Nur Text";
        font-family:Consolas;
        mso-fareast-language:EN-US;}
p.PlainText, li.PlainText, div.PlainText
        {mso-style-name:"Plain Text";
        mso-style-link:"Plain Text Char";
        margin:0cm;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        mso-fareast-language:EN-US;}
span.PlainTextChar
        {mso-style-name:"Plain Text Char";
        mso-style-priority:99;
        mso-style-link:"Plain Text";
        font-family:Consolas;}
span.E-MailFormatvorlage23
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
span.E-MailFormatvorlage24
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 122.9pt 72.0pt 122.9pt;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:1924483783;
        mso-list-type:hybrid;
        mso-list-template-ids:1900573576 201916439 201916441 201916443 201916431 201916441 201916443 201916431 201916441 201916443;}
@list l0:level1
        {mso-level-number-format:alpha-lower;
        mso-level-text:"%1\)";
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l0:level2
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l0:level3
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
@list l0:level4
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l0:level5
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l0:level6
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
@list l0:level7
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l0:level8
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-18.0pt;}
@list l0:level9
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
ol
        {margin-bottom:0cm;}
ul
        {margin-bottom:0cm;}
--></style></head><body lang=DE-CH link="#0563C1" vlink="#954F72"><div class=WordSection1><p class=MsoNormal><span lang=EN-US>Yes, you’re right. It’s not in the Oberon report. However the inner core heavily depends on it.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>NW sees Oberon is a high level language able to do low level programming. Proof: one can write a complete OS with it.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>This statement is only true, if you have these “undocumented” extensions in the compiler.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>If you don’t have the ARRAY OF BYTE feature, you could do it the pure Oberon way with type extensions. But then you don’t have the automatic checks whether the type sizes of the parameters really fit. You would have to add runtime checks.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>The other one being that the compiler accepts “0E7000000H” as INTEGER. Strictly speaking, it’s not allowed (either an INTEGER is negative. In Oberon you can only generate negative numbers by involving a “-“ somewhere. Or it’s positive, then it’s too big for an 31bit number + sign bit)<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>As you know the compiler is full with these constants.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>The Oberon Report is short but unfortunately not complete.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>br<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>Jörg<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span style='font-size:12.0pt;color:black'>Von: </span></b><span style='font-size:12.0pt;color:black'>Oberon <oberon-bounces@lists.inf.ethz.ch> im Auftrag von Chris Burrows <chris@cfbsoftware.com><br><b>Antworten an: </b><chris@cfbsoftware.com>, ETH Oberon and related systems <oberon@lists.inf.ethz.ch><br><b>Datum: </b>Dienstag, 16. Juni 2020 um 08:19<br><b>An: </b>ETH Oberon and related systems <oberon@lists.inf.ethz.ch><br><b>Betreff: </b>Re: [Oberon] Type compatibility rules for Pointers</span><span style='font-size:12.0pt;color:black;mso-fareast-language:DE'><o:p></o:p></span></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>Jörg<o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'>I seem to recall being involved, with others, in an email review of this list. My recollection was that is was somebody else rather than Karl – there may be another similar list in existence. As far as I know it is solely an unofficial interpretation of the report. As he says in the introduction:</span><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'>“To fill in the missing pieces, appendix A from <i>The Programming Language Oberon-2</i> (1993) by Hanspeter Mössenböck and Niklaus Wirth is used here as a template, with adjustments for the 2016 edition of Oberon.”</span><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'> </span><o:p></o:p></p><ol style='margin-top:0cm' start=1 type=a><li class=MsoListParagraph style='margin-left:0cm;mso-list:l0 level1 lfo2'><span style='color:#1F497D'>I’ll rephrase that question: Who says this list is incorrect and why?</span><o:p></o:p></li></ol><p class=MsoNormal><span style='color:#1F497D'> </span><o:p></o:p></p><ol style='margin-top:0cm' start=2 type=a><li class=MsoListParagraph style='margin-left:0cm;mso-list:l0 level1 lfo2'><span style='color:#1F497D'>As I have stated here before, the Project Oberon compiler is not a reference compiler. It includes some additions, some variations and some exclusions from the Language Report. It is highly likely the same applies to every other Oberon compiler in existence – in the real world there will inevitably be some grey areas. </span><o:p></o:p></li></ol><p class=MsoListParagraph><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoListParagraph><span style='color:#1F497D'>The special case of ARRAY OF BYTE (when equivalenced to another type of the same size) is one such example. It is an undocumented extended feature of the Project Oberon compiler. It is not currently part of the language definition and cannot be expected to work in all Oberon compilers.</span><o:p></o:p></p><p class=MsoListParagraph><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'>Regards,</span><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'>Chris Burrows</span><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'>CFB Software</span><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'><a href="https://www.astrobe.com">https://www.astrobe.com</a></span><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'> </span><o:p></o:p></p><div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='mso-fareast-language:EN-AU'>From:</span></b><span lang=EN-US style='mso-fareast-language:EN-AU'> Joerg [mailto:joerg.straube@iaeth.ch] <br><b>Sent:</b> Tuesday, 16 June 2020 3:00 PM<br><b>To:</b> chris@cfbsoftware.com; ETH Oberon and related systems<br><b>Subject:</b> Re: [Oberon] Type compatibility rules for Pointers</span><o:p></o:p></p></div></div><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>Chris<o:p></o:p></p><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal>Where does Karl Landström have the missing info from?<o:p></o:p></p></div><div><p class=MsoNormal>a) own interpretation of the report<o:p></o:p></p></div><div><p class=MsoNormal>b) compiler code<br><br>If a) who says this list is correct?<o:p></o:p></p></div><div><p class=MsoNormal>If b) the special case of ARRAY OF BYTE is missing.<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p><div><p class=MsoNormal>br<o:p></o:p></p><div><p class=MsoNormal>Jörg<o:p></o:p></p></div></div><div><p class=MsoNormal><br><br><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal style='margin-bottom:12.0pt'>Am 16.06.2020 um 03:40 schrieb Chris Burrows <<a href="mailto:chris@cfbsoftware.com">chris@cfbsoftware.com</a>>:<o:p></o:p></p></blockquote></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal><o:p></o:p></p><p class=MsoPlainText>> <span lang=EN-US style='mso-fareast-language:EN-AU'>-----Original Message-----</span><o:p></o:p></p><p class=MsoPlainText>> <span lang=EN-US style='mso-fareast-language:EN-AU'>From: Oberon [<a href="mailto:oberon-bounces@lists.inf.ethz.ch">mailto:oberon-bounces@lists.inf.ethz.ch</a>] On Behalf Of chris</span><o:p></o:p></p><p class=MsoPlainText>> <span lang=EN-US style='mso-fareast-language:EN-AU'>Sent: Tuesday, 16 June 2020 5:37 AM</span><o:p></o:p></p><p class=MsoPlainText>> <span lang=EN-US style='mso-fareast-language:EN-AU'>To: ETH Oberon and related systems</span><o:p></o:p></p><p class=MsoPlainText>> <span lang=EN-US style='mso-fareast-language:EN-AU'>Subject: Re: [Oberon] Type compatibility rules for Pointers</span><o:p></o:p></p><p class=MsoPlainText>> <o:p></o:p></p><p class=MsoPlainText>> On Mon, 15 Jun 2020 21:42:39 +0200, Michael Schierl wrote:<o:p></o:p></p><p class=MsoPlainText>> > Are you equally confused when you replace POINTER TO R by ARRAY 42 OF<o:p></o:p></p><p class=MsoPlainText>> > BYTE or even by INTEGER?<o:p></o:p></p><p class=MsoPlainText>> ><o:p></o:p></p><p class=MsoPlainText>> > i.e.<o:p></o:p></p><p class=MsoPlainText>> ><o:p></o:p></p><p class=MsoPlainText>> > TYPE I1 = INTEGER; I2 = INTEGER;<o:p></o:p></p><p class=MsoPlainText>> >   A1 = ARRAY 42 OF BYTE;<o:p></o:p></p><p class=MsoPlainText>> >   A2 = ARRAY 42 OF BYTE;<o:p></o:p></p><p class=MsoPlainText>> <o:p></o:p></p><p class=MsoPlainText>> Yes I am. In my understanding this breaks the longstanding tradition since<o:p></o:p></p><p class=MsoPlainText>> the Modula days, that type compatibility is declared by name and not<o:p></o:p></p><p class=MsoPlainText>> inferred by structure (Only exception are procedure types for obvious<o:p></o:p></p><p class=MsoPlainText>> reasons and type extension).<o:p></o:p></p><p class=MsoPlainText>> <o:p></o:p></p><p class=MsoPlainText>> > As I understand it, of all custom types only record types have identity.<o:p></o:p></p><p class=MsoPlainText>> > All other types are just aliases of what is on the other side of the<o:p></o:p></p><p class=MsoPlainText>> > equals sign. So it should not matter if you replace every occurrence<o:p></o:p></p><p class=MsoPlainText>> > of<o:p></o:p></p><p class=MsoPlainText>> > I1 by INTEGER or A1 by ARRAY 42 OF BYTE<o:p></o:p></p><p class=MsoPlainText>> <o:p></o:p></p><p class=MsoPlainText>> The declaration<o:p></o:p></p><p class=MsoPlainText>>      I1 = INTEGER;<o:p></o:p></p><p class=MsoPlainText>> declares an alias and no new type. ARRAY 42 OF BYTE is a new type.<o:p></o:p></p><p class=MsoPlainText>> <o:p></o:p></p><p class=MsoPlainText>> The Oberon-2 report for example gives the first formal definition of "same<o:p></o:p></p><p class=MsoPlainText>> type" I know of and it clearly states in 1. that same types means same type<o:p></o:p></p><p class=MsoPlainText>> identifier.<o:p></o:p></p><p class=MsoPlainText>> <o:p></o:p></p><p class=MsoPlainText>> "Same types"<o:p></o:p></p><p class=MsoPlainText>>      Two variables a and b with types Ta and Tb are of the same type if<o:p></o:p></p><p class=MsoPlainText>>      1. Ta and Tb are both denoted by the same type identifier, or<o:p></o:p></p><p class=MsoPlainText>>      2. Ta is declared to equal Tb in a type declaration of the form Ta<o:p></o:p></p><p class=MsoPlainText>> =<o:p></o:p></p><p class=MsoPlainText>>              Tb, or<o:p></o:p></p><p class=MsoPlainText>>      3. a and b appear in the same identifier list in a variable, record<o:p></o:p></p><p class=MsoPlainText>>              field, or formal parameter declaration and are not open<o:p></o:p></p><p class=MsoPlainText>> arrays.<o:p></o:p></p><p class=MsoPlainText>> <o:p></o:p></p><p class=MsoPlainText>> > I am not sure where I have this from (I can see that it is not<o:p></o:p></p><p class=MsoPlainText>> > actually defined in the Oberon 07 Report), perhaps this is just from<o:p></o:p></p><p class=MsoPlainText>> > experience from other programming languages.<o:p></o:p></p><p class=MsoPlainText>> <o:p></o:p></p><p class=MsoPlainText>> Looks you are right about Oberon-07. The Oberon-07 report is very vague<o:p></o:p></p><p class=MsoPlainText>> about this.<o:p></o:p></p><p class=MsoPlainText>> <o:p></o:p></p><p class=MsoPlainText> <o:p></o:p></p><p class=MsoPlainText><span style='color:black'>There has been much debate about this in the past. Not all of the rules are explicitly spelt out in the Language Report. In the introduction to the Language Report Wirth says:</span><o:p></o:p></p><p class=MsoPlainText><span style='color:black'> </span><o:p></o:p></p><p class=MsoPlainText><span style='color:black'>“… What remains unsaid is mostly left so intentionally, either because <b><i>it is derivable</i></b> from stated rules of the language…”</span><o:p></o:p></p><p class=MsoPlainText><span style='color:black'> </span><o:p></o:p></p><p class=MsoPlainText><span style='color:black'>However, that does require the reader to exercise some mental gymnastics in cases like these. If you prefer a more explicit version, I recommend this one. I believe it to be correct but would be interested if anybody spots any flaws:</span><o:p></o:p></p><p class=MsoPlainText><span style='color:black'> </span><o:p></o:p></p><p class=MsoPlainText><a href="https://miasap.se/obnc/type-compatibility.html">https://miasap.se/obnc/type-compatibility.html</a><o:p></o:p></p><p class=MsoPlainText> <o:p></o:p></p><p class=MsoPlainText>Regards,<o:p></o:p></p><p class=MsoPlainText>Chris Burrows<o:p></o:p></p><p class=MsoPlainText>CFB Software<o:p></o:p></p><p class=MsoPlainText><a href="https://www.astrobe.com">https://www.astrobe.com</a><o:p></o:p></p><p class=MsoPlainText><span style='color:black'> </span><o:p></o:p></p><p class=MsoPlainText><span style='color:black'> </span><o:p></o:p></p><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Times New Roman",serif;mso-fareast-language:EN-AU'>--<br><a href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br><a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a></span><o:p></o:p></p></div></blockquote></div></div><p class=MsoNormal><span style='mso-fareast-language:DE'>-- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon <o:p></o:p></span></p></div></body></html>