Re: Array conversion and bounds

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2018-04-15 20:21, Niklas Holsti wrote:
> On 18-04-15 16:24 , Dmitry A. Kazakov wrote:
>> On 2018-04-15 15:11, Niklas Holsti wrote:
>>> On 18-04-15 15:34 , Dmitry A. Kazakov wrote:
>>>> On 2018-04-15 12:37, Niklas Holsti wrote:
>>>>> On 18-04-15 12:36 , Dmitry A. Kazakov wrote:
>>>>>> Do array bounds slide during conversion? Consider this:
>>>>>>
>>>>>>    type A is array (Integer range <>) of Whatever;
>>>>>>    type B is array (Unsigned_32 range <>) of Whatever;
>>>>>>
>>>>>>    X : A (-10..-1);
>>>>>>    Y : B (1..10);
>>>>>> begin
>>>>>>    Y := B (X); -- Is this OK?
>>>>>>
>>>>>> If bounds slide it must be OK, if bounds do not slide, it must raise
>>>>>> Constraint_Error.
>>>>>>
>>>>>> Any language lawyers?
>>>>>
>>>>> I believe the bounds should _not_ slide, because the "target subtype"
>>>>> of the conversion is type B, which is an _unconstrained_ array 
>>>>> subtype.
>>>>
>>>> Better to say, they should, but they do not.
>>>
>>> Ok, if I read the RM correctly (and you seem to agree with me) they
>>> "do not" slide when the target subtype is unconstrained.
>>
>> It is an unsafe choice, obviously.
> 
> Not obvious, I think.
> 
> I think you'll agree with me that Ada array types are a blend (sometimes 
> uneasy) of two kinds of conceptual data structures: (1) maps from the 
> index type(s) to the component type, and (2) ordered sequences or 
> matrices of values of the component type.
> 
> An example of the first case is an array indexed by calendar year number 
> and giving the average global temperature for that year. An example of 
> the second case is a string, where the index (usually) shows only the 
> relative order of characters in the string.
> 
> In the first case, the association of a specific index value with the 
> corresponding component value is meaningful, and should not be lightly 
> destroyed by sliding, because sliding could give unexpected associations 
> -- for example, the global average temperature for 2005 could wrongly 
> become associated with the year 1. In the second case, sliding is 
> harmless, as the string (1 => 'H', 2 => 'i') is (in most cases) 
> equivalent to the string (100 => 'H', 101 => 'i').

This is all true, but it does not prove the case. Because

1. Indices do slide anyway:

    Y (1..10) := X (B (2..11)); -- This is OK

they raise Constraint_Error only if the starting point of the sliding 
index is out of the range of the target index type.

2. There is no way one the language could judge the way indices to be 
converted. Either an array conversion must be A) always illegal, or B) 
use user-provided index mapping, C) or slide taking only the length in 
account.

>>> Is there some reason why you cannot use the constrained-target-subtype
>>> method to force sliding?
>>
>> Considering this example:
>>
>>    type A is array (Integer range <>) of Whatever;
>>    type B is array (Unsigned_32 range <>) of Whatever;
>>
>>    X : A (-1000..-1);
>>    Y : B (1..200);
>> begin
>>    Y (10..19) := B (X (-19..-10));
>>
>> Do you propose this?
>>
>>    declare
>>       subtype BB is B (10..19);
>>    begin
>>       Y (10..19) := BB (X (-19..-10));
>>    end;
> 
> Yes. And BB might have any index range, as long as BB'Length = 10.
> 
> I admit that I did not know by heart these rules (sliding for 
> constrained target subtype, no sliding for unconstrained) but now I feel 
> that they are rather natural. A conversion to a constrained target 
> subtype says "give me these index bounds, and no others" so sliding is 
> apt. A conversion to an unconstrained target subtype says "I do not 
> require specific index bounds, so the bounds of the source array are as 
> good as any others".

And the compiler chooses the ones that would cause Constraint_Error? 
Constraint_Error is definitely not as good as no Constraint_Error.

> The case of an unconstrained target subtype, but where the source bounds 
> are not (or might not be) in the target index subtype's range, is 
> perhaps a trap in the language, and worth a compiler warning.

It is impossible to warn, because the bounds are unknown until run-time. 
This is a very unsafe choice.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de