[Oberon] Clarifying type compatibility in Oberon-07

[Jörg]

Sorry, I meant   b:= X.a  (not A.a)
Jörg

> Am 08.10.2017 um 06:09 schrieb Jörg <joerg.straube at iaeth.ch>:
> 
> Chris
> 
> We are talking about a typed language are we? Not C or assembler...
> If something is named or not has nothing to do with if they should be compatible or not.
> 
> 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 := A.a
> 
> So, you would allow this?
> 
> br
> Jörg
> 
>> Am 08.10.2017 um 02:26 schrieb Chris Burrows <chris at cfbsoftware.com>:
>> 
>>> -----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
>> 
>> 
>> 
>> --
>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>