[Oberon] Clarifying type compatibility in Oberon-07

[Jörg]

Hi August

see inline

> Am 04.10.2017 um 21:00 schrieb August Karlstrom <fusionfile at gmail.com>:
> 
> On 2017-10-04 18:11, Jörg wrote:
>> In my point of view Appendix A for Oberon-07 would look like this.[...]
> 
> (Your strikethroughs and colors don't show in ASCII so I cannot include any quoted context.)
> 
> Our goal in this thread is to reach a consensus about how a conforming Oberon-07 compiler should behave (when it comes to type compatibility) and document it using appendix A in the Oberon-2 report as a template. Note also that Niklaus Wirth has said that his implementation (the PO2003 compiler) should not be taken as a reference for compiler developers.
> 
> * LONGINT is not in the report so it should be dropped.

Strictly speaking, you are right: LONGINT is NOT part of the language report. NW’s source code is full of LONGINTs. This is because he took quite some code from the old compiler and simplified it. My assumption is: he was too lazy to write in almost all MODULES as first statement TYPE LONGINT = INTEGER, that he decided to include that statement in the compiler.
That was the reason why I took the green color and not the red color.
As a general rule of thumb: NW seems to apply the following rule: If something has to have 4 bytes, he calls it LONGINT, If the size is not so important (index, counter..) he seems to declare it as INTEGER. The size of INTEGER (and SET) is not mentioned in the report, it’s fixed to a specific value by the compiler.

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

> * Under "Assignment compatible" you don't mention assignment of open arrays.

open arrays only exist as formal parameter of a procedure not as a variable. Assignment rules are for variables. In my point of view open arrays are covered in Array rule 2.

> 
> * Paragraph 4 of "Array compatible" (ARRAY n OF BYTE...) must be a compiler extension since it cannot be deduced from the language report.

That’s indeed strange. In one of the previous posts Chris highlighted that this was possible. I was not aware of this and was thinking the same. If I remember correctly, I browsed then thru the report and indeed found a sentence explicitly mentioning it. I re-did that today, I can’t find it back anymore. Seems, I’m getting old… Feel free to delete it. I have to admit it’s a feature that simplifies things. It frees your (low level) code of a lot of SYSTEM.VAL(LONGINT, …)

> You never mention structural equivalence in assignment of expressions of array or procedure type, so the question is if that is an undocumented "language extension" in the PO2003 compiler.

In my point of view this topic is covered by the last chapter titled „Matching formal parameter lists" 

> Any more comments?
> 
> 
> -- August
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon