[Oberon] Clarifying type compatibility in Oberon-07

[Chris Burrows]

> -----Original Message-----
> From: Jörg [mailto:joerg.straube at iaeth.ch]
> Sent: Sunday, 8 October 2017 2:40 PM
> To: chris at cfbsoftware.com; ETH Oberon and related systems
> Subject: Re: [Oberon] Clarifying type compatibility in Oberon-07
> 
> Chris
> 
> We are talking about a typed language are we? Not C or assembler...

Yes. However I prefer to keep an open mind and take a pragmatic approach to these sorts of issues rather than a strict dogmatic approach. As soon as we accept the concept of open array parameters the strict name compatibility rule is compromised. 

Pascal went too far along the dogmatic route. Oberon represents a more pragmatic approach. It is a product resulting from decades of the author's real world experience.

> If something is named or not has nothing to do with if they should be
> compatible or not.
>

In the context of name equivalence vs. structural equivalence that statement is false.
 
> MODULE X;
> TYPE A = ARRAY 30 OF INTEGER;
> VAR a*: A;
> 
> MODULE Y;
> IMPORT X
> TYPE B = ARRAY 30 OF INTEGER;
> VAR b: B
> 
> b := X.a
> 
> So, you would allow this?
> 

That is a different scenario and would need to be considered separately. The conclusion does not necessarily follow from my previous example.

However, the short answer is 'No'. Exporting 'a' serves no purpose without also exporting 'A'. 

If A is exported as well then currently the answer is 'Yes'. The Astrobe compiler accepts it (and so does the RISC5 compiler). It all depends on your interpretation of the words 'same', 'equal', 'identical'. 

In 'Programming in Oberon' (2015) when discussing parameter compatibility, Wirth says:

"If a formal parameter type denotes an array structure, its corresponding actual parameter must be an array of the *identical type*. This implies that it must have *elements of identical type* and the *same bounds* of the index range." That sounds more like structure compatibility than name compatibility to me. 

I'm not saying you are wrong and I am right. I'm saying that our interpretations are different. I have used the interpretation that I believe is most useful when programming microcontrollers with Oberon. 

If a later version of the Oberon Report appears which convinces me my interpretation is unsound then I'll reconsider.

Regards,
Chris Burrows
CFB Software
http://www.astrobe.com