gm2
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gm2] VAR array parameter type compatibility


From: SiTex Graphics
Subject: Re: [Gm2] VAR array parameter type compatibility
Date: Mon, 1 Feb 2010 23:20:51 -0500

Hi Gaius,

Attached is another VAR array case that fails.

-Scott


On Mon, Feb 1, 2010 at 5:18 PM, Gaius Mulley <address@hidden> wrote:
> Fischlin Andreas <address@hidden> writes:
>
>> Hi all,
>>
>> I agree, this compatibility should actually work and the compiler
>> should accept types which have been made equal. Other examples are:
>>
>> TYPE
>>       MYSHORTREAL = REAL;
>>
>> TYPE
>>       PROCA = PROCEDURE (VAR ARRAY OF REAL);
>>       PROCB = PROCEDURE (VAR ARRAY OF MYSHORTREAL);
>>
>> VAR
>>       pa: PROCA; pb: PROCB;
>>         x: ARRAY [0..1] OF REAL;
>>         y: ARRAY [0..1] OF MYSHORTREAL;
>>
>> PROCEDURE ProcA(VAR z: ARRAY OF REAL);
>> PROCEDURE ProcB(VAR z: ARRAY OF MYSHORTREAL);
>>
>> then pa and pb should be type compatible and interchangeably usable,
>> i.e. all following statements should all be legal:
>>
>>       x := y;
>>       pa := ProcA; pb := ProcB;
>>       pa(x); pa(y); pb(x); pb(y);
>>       pa := ProcB; pb := ProcA;
>>       pa(x); pa(y); pb(x); pb(y);
>>
>>
>> Regards,
>> Andreas
>>
>>
>>
>> On 01/Feb/2010, at 22:07 , SiTex Graphics wrote:
>>
>>> Hi Gaius,
>>>
>>> I have a case where GM2 appears to enforce different type
>>> compatibility rules depending on whether a VAR array parameter is a
>>> variable or the parameter in a procedure.
>>>
>>> With
>>>
>>> TYPE
>>>  fooADDRESS = ADDRESS;
>>>
>>> VAR
>>>  foo : ARRAY [0..9] OF fooADDRESS;
>>>
>>> GM2 accepts a call to
>>>
>>> PROCEDURE DoAddress(VAR a : ARRAY OF ADDRESS)
>>>
>>> passing foo.  However, the following call produces a compiler error:
>>>
>>> PROCEDURE DoFoo(VAR f : ARRAY OF fooADDRESS);
>>> BEGIN
>>>  DoAddress(f);
>>> END DoFoo;
>>>
>>> "'f' cannot be passed to a VAR formal parameter"
>>>
>>> Test code attached.  Compile with
>>>
>>> gm2 -fiso -c arraytype.mod
>>>
>>> -Scott
>
> Hi Scott and Andreas,
>
> I agree a bug - it looks as if the type equivalence checking code has
> a bug inside the parameter checking component.  Thanks for the test
> code - it should make tracking this bug down easier
>
> regards,
> Gaius
>

Attachment: chararray.mod
Description: audio/mod


reply via email to

[Prev in Thread] Current Thread [Next in Thread]