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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,5f5a48f21d7f7525 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Inferring array index type from array object Date: Tue, 29 Jun 2010 01:18:10 +0300 Organization: Tidorum Ltd Message-ID: <88sld2F9m8U1@mid.individual.net> References: <6b20ed09-efc1-4df7-90f9-5e141482e8d0@d37g2000yqm.googlegroups.com> <1305oqccr1h2t$.x33x4oxwd84d$.dlg@40tude.net> <88ec2vF3uqU1@mid.individual.net> <88f9osFmcmU1@mid.individual.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net 52SXoUYBVaYDaGEp1WCQHwSkXkb8cB1GY1w1RkatvVcNXJmNEn Cancel-Lock: sha1:jK3ocLNv9Rw/gr1i4IV1C77OpgM= User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328) In-Reply-To: Xref: g2news1.google.com comp.lang.ada:11973 Date: 2010-06-29T01:18:10+03:00 List-Id: Warren wrote: > Niklas Holsti expounded in news:88f9osFmcmU1@mid.individual.net: > >> Warren wrote: >>> Niklas Holsti expounded in news:88ec2vF3uqU1@mid.individual.net: >>>> Dmitry A. Kazakov wrote: >>>>> On Wed, 23 Jun 2010 00:30:23 -0700 (PDT), Maciej Sobczak wrote: >>> .. >>>>>> 2. Is it possible to declare the index variable without hardcoding >>>>>> the index type (that is, to infer it from the array object)? >>>>> No, without improving the type system. E.g. introducing abstract >>>>> index types, and abstract range types (or more general sets of index >>>>> types), and abstract composite types like arrays. >>>> I don't think such large language changes would be necessary. The >>>> expression S'Range gives the compiler all the information about the >>>> type and its constraints, so I see no reason why Ada could not be >>>> extended simply to allow S'Range in a variable declaration, as in the >>>> above quoted "I : S'Range". The declared variable "I" would have the >>>> same (sub)type as the loop counter in "for I in S'Range loop ...". >>> I think most would agree that this is a "convenience" feature. >> Yes, but in other contexts, when we advocate Ada, we often make a big >> point of the "convenience" of the 'Range attribute for arrays, such as >> "No need to pass extra parameters for array index bounds, just use >> 'Range". The suggestion to let variables be declared by the "type" >> S'Range (or, if desired, a new attribute S'Index_Type) has a similar >> advantage (but a weaker one, I admit). > > But how far down that road do you want to go? This is > the crux of the issue. > > I'd find ++X or X += n convenient. But should that be > implemented in Ada? I'm ok with leaving it out. > > At some point, you have to draw a line in the sand. "Convenience" is not always opposed to "the Ada way". Ada strives to be readable and correctness-prone (that is, the opposite of error-prone). I thnk that there are features that could be added to Ada that favour these goals but also increase convenience. I think Ada could well support an add-and-assign syntax, for example in the syntax X +:= 1 (or X := * + 1 as it was written IIRC in Burroughs Extended Algol). It seems to me that if "X" is a longish name, perhaps with indexing and component selection, having it appear only once is both more readable and less error-prone than forcing it to be written and read twice, as in the standard X := X + 1. But the new syntax should be defined as an abbreviation for the standard form (albeit with only one evaluation of the name X), not as a new operator. In C/C++, these updating assignment operators cause problems when they are used as (parts of) expressions, which I would not want to see in Ada. To return to the case of using S'Range or S'Index_Type to declare variables, assume that we have S : array (Framp_Number) of Neighness_Value; The question is then to compare the readability and error-proneness of the current standard form I : Framp_Number; ... ... S(I) ... with the proposed alternative I : S'Range; -- or S'Index_Type; ... ... S(I) ... I don't see any general reason to prefer one or the other. The former style emphasises that "I" holds a Framp_Number value, with less emphasis on "I" being a valid index for S, while the latter style has the opposite emphasis. I would favour the latter style if the main or only role of "I" is to index S. This could avoid errors if the index type of S is later changed, and such a change would also be easier (less editing of text). Of course, even if such features agree with the Ada way, it may not be worth-while to add them to Ada. That is a cost-benefit trade-off where the "cost" is in definition, implementation, testing, and maintenance of standards and compilers, but not a "cost" as some kind of "degradation" of the qualities of the Ada language. At most, there may be some "cost" in fully learning the (now larger) language. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .