From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.unit0.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Array conversion and bounds Date: Sun, 15 Apr 2018 21:21:13 +0300 Organization: Tidorum Ltd Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net JwYe2WE0XGpQ1vqiwRc09AWICv5Wswt5sQIZEYqrFU7eB+yGxT Cancel-Lock: sha1:rQKs7avGmNF1/JsIk4UpYgCsiuM= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: Xref: reader02.eternal-september.org comp.lang.ada:51527 Date: 2018-04-15T21:21:13+03:00 List-Id: 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'). >> 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". 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. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .