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=0.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,2e6723b897ab47fb X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.66.77.3 with SMTP id o3mr1189195paw.13.1344847634974; Mon, 13 Aug 2012 01:47:14 -0700 (PDT) Path: p10ni51394108pbh.1!nntp.google.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!news-in-01.newsfeed.easynews.com!easynews.com!easynews!novia!news-peer1!btnet!zen.net.uk!hamilton.zen.co.uk!xlned.com!feeder3.xlned.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!80.86.168.138.MISMATCH!news-feed.eu.lambdanet.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Ada.Locales pseudo-string types Date: Wed, 08 Aug 2012 17:01:23 +0300 Organization: Tidorum Ltd Message-ID: References: <78707b6e-88a3-453a-a37c-840f7a62e703@googlegroups.com> <7303f906-0f6a-4d97-ae15-36b4056ede6c@googlegroups.com> <257b4f44-b6c6-4c79-8c6e-dec947a3ce25@googlegroups.com> <1o3by92cb82px$.1gavjw6p23du6$.dlg@40tude.net> <8zenu4qplfb$.1uc9oi1819c3v$.dlg@40tude.net> Mime-Version: 1.0 X-Trace: individual.net 6hjDAKm4W4Nm9JGFZK7EgQbkKcIjSX2xynAaLZakAJwAQGzYT8SdUedLrjj/dSdJR7 Cancel-Lock: sha1:QU4DyvUKy5/10eSMS91JbQn5kCA= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 In-Reply-To: <8zenu4qplfb$.1uc9oi1819c3v$.dlg@40tude.net> X-Received-Bytes: 4216 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Date: 2012-08-08T17:01:23+03:00 List-Id: On 12-08-08 14:59 , Dmitry A. Kazakov wrote: > On Wed, 08 Aug 2012 14:14:26 +0300, Niklas Holsti wrote: > >> On 12-08-08 11:09 , Dmitry A. Kazakov wrote: >>> On Wed, 08 Aug 2012 10:37:51 +0300, Niklas Holsti wrote: >>> >>>> On 12-08-08 10:18 , Dmitry A. Kazakov wrote: >>>>> On Wed, 08 Aug 2012 10:04:37 +0300, Niklas Holsti wrote: >>>>> >>>>>> The rule does seem surprisingly rigid, for a value conversion. (The >>>>>> Annotated RM does not explain or motivate it.) >>>>> >>>>> Ada didn't appreciate structured type equivalence in earlier times. These >>>>> rules were designed before anonymous access types crept in. >>>> >>>> But we are talking about explicitly requested type conversions, not >>>> implicit type equivalence. As I understood it, at least. >>> >>> Yes, but the validity of this conversion relies on an inferred equivalence >>> of the [sub]types of the elements. >> >> No, I would rather think that the explicitly requested array-type >> conversion implies requests to convert the index [sub]types and the >> element [sub]types, too. > > Yes, but the way this conversion is constructed is based on the assumption > that subtypes of the element are equivalent up to a conversion. > > BTW, if you go that far you should also allow conversions between any array > types of convertible elements. E.g. between arrays of floats and arrays of > integers etc. Well, for explicit value conversions, why not? But I don't think that there is significant need for such conversions on the array level. What I have sometimes found annoying is that operations on arrays of a parent type cannot easily be applied to arrays of a derived type. For example: type Parent is (A, B, C); type Parent_Arr is array (Positive range <>) of Parent; procedure Print (Item : in Parent_Arr) ... end Print; type Child is new Parent; type Child_Arr is array (Positive range <>) of Child; The operation Print on Parent_Arr is not inherited by Child_Arr, and conversion from Child_Arr to Parent_Arr is not allowed. Not a big problem, but one that has sometimes irritated me and forced me to use work-arounds (writing a special Print for Child_Arr, in this case). -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .