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.180.82.226 with SMTP id l2mr1164758wiy.1.1344847885449; Mon, 13 Aug 2012 01:51:25 -0700 (PDT) Path: n2ni106821942win.0!nntp.google.com!volia.net!news2.volia.net!feed-A.news.volia.net!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!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 14:14:26 +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> Mime-Version: 1.0 X-Trace: individual.net Mf/ls9yHPy68cLUP+hpVfg/F9C94fkhpSrjv705mo2oxjCSZnvIc56ikwkFq/oTPl+ Cancel-Lock: sha1:HA6Lbva/p8EWk6gEIe2eIuoMwBI= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 In-Reply-To: <1o3by92cb82px$.1gavjw6p23du6$.dlg@40tude.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Date: 2012-08-08T14:14:26+03:00 List-Id: 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. > Ada considered them equivalent nominally. Yes, but in order to be sure that the conversion requires no active machine code and can be done just by relabeling the type of a reference to the array. > A less conservative approach is to consider only those for which > constraints are no less permissive than ones of the target elements. Yes (I wrote about that in another reply). >>>> For a value conversion, >>>> the default could be to convert element by element, and the compiler >>>> could then optimize this conversion based on what it can deduce >>>> statically about the matching of the source and target subtypes. >>> >>> Could be interesting when elements themselves are arrays of discriminated >>> record subtypes constrained via discriminants with array components again >>> constrained etc. >> >> Sure, but this should not require much new intelligence in the compiler. > > True. > > BTW, there is another issue with that. What happens when some element > cannot be converted? Constraint_Error is to propagate. What happens with > the target. Will be previously assigned elements rolled back? A matter of definition. Ada already contains the concept of a "disrupted" assignment, which can be caused by the failure of a language-defined check and in which the variable being assigned then becomes abnormal. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .