[Oberon] Clarifying type compatibility in Oberon-07

[Chris Burrows]

> -----Original Message-----
> 
> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of J
> rg
> Sent: Friday, 6 October 2017 1:55 AM
> To: ETH Oberon and related systems
> Subject: Re: [Oberon] Clarifying type compatibility in Oberon-07
> 
> Hi Andreas
> 
> Of course we could do so, but I wonder why?
> If I understand you correctly you want to allow the following VAR
>       a: ARRAY 30 OF CHAR;
>       b: ARRAY 30 OF CHAR;
>       a := b;
> 
> Currently, this is not allowed, because there are several ways to
> allow this already Method 1:
>       VAR a, b: ARRAY 30 OF CHAR;
> Method 2:
>       TYPE String30 = ARRAY 30 OF CHAR;
>       VAR
>       a: String30;
>       b: String30;
> 

What if the two declarations are separate e.g.?

--------------------------------
MODULE M0; 

VAR
  a*: ARRAY 32 OF INTEGER;

...
...
--------------------------------
MODULE M1;

IMPORT M0;

VAR
  a: ARRAY 32 OF INTEGER;  
BEGIN
a := M0.a;
...
...
-------------------------------

or this one:

-------------------------------
MODULE Array6;

VAR
  g: ARRAY 10 OF INTEGER;
  
PROCEDURE P;
VAR
  a: ARRAY 10 OF INTEGER; 
BEGIN
  a := g;
END P;

END Array6.  
-------------------------------

If the programmer has chosen to use anonymous arrays it might well be reasonable to assume he is not concerned about name equivalence so why should he be inconvenienced but prohibiting assignments? Surely not just because it conflicts with somebody else's personal taste? 

I'm sure there are many more examples. However, it is premature to discuss solutions before *every single one* of the possible practical scenarios have been elaborated. To do so risks unintentionally prohibiting useful applications or allowing badly-behaved ones. Once this is done a test suite of examples to exercise all of these (positive and negative) cases should be developed. As well as confirming that the eventual solution is correct it would form a useful addition to the report for those who enjoy contemplating these issues or for other compiler implementers.

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