Inferring array index type from array object
in [ADA]
|
From: Niklas Holsti on 28 Jun 2010 18:18 Warren wrote: > Niklas Holsti expounded in news:88f9osFmcmU1(a)mid.individual.net: > >> Warren wrote: >>> Niklas Holsti expounded in news:88ec2vF3uqU1(a)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 . @ .
From: Adam Beneschan on 28 Jun 2010 21:49 On Jun 28, 3:18 pm, Niklas Holsti <niklas.hol...(a)tidorum.invalid> wrote: > "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 see http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai05s/ai05-0187-1.txt?rev=1.6 -- Adam
From: (see below) on 28 Jun 2010 22:10 On 29/06/2010 02:49, in article 73ee19f6-1591-47ba-9dd0-3932935422f7(a)v13g2000prn.googlegroups.com, "Adam Beneschan" <adam(a)irvine.com> wrote: > On Jun 28, 3:18�pm, Niklas Holsti <niklas.hol...(a)tidorum.invalid> > wrote: > >> "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 > > see http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai05s/ai05-0187-1.txt?rev=1.6 Sigh! -- Bill Findlay <surname><forename> chez blueyonder.co.uk
From: Warren on 29 Jun 2010 12:56 Niklas Holsti expounded in news:88sld2F9m8U1(a)mid.individual.net: > Warren wrote: >> Niklas Holsti expounded in news:88f9osFmcmU1(a)mid.individual.net: >>> Warren wrote: >>>> Niklas Holsti expounded in news:88ec2vF3uqU1(a)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)? .... >>>>> 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). .... >> 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. No argument on that. > 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 ... One thing that really irks me (in lack of convenience) is the lack of certain functions in the library support. For example, I was looking for the inverse of a complex number function. Did I missed it? My googling didn't turn up much, nor did grep on the package hdrs. So because it is missing (AFIK), I had to google it and figure out how it is done and code it myself. Wouldn't it be safer if the function was already provided and tested? Wouldn't it also be more accurately coded (floating point can be tricky)? At least it would be tested. IIRC, I ran into the similar issues with some other functions (ATAN2??). The LOG10() issue was resolved when I discovered there is a base argument in LOG(), so that was just my own "user error". But even if a function is considered "trivial", I think it would be "safer" to include it. Additionally, having them provided means that they will be coded for the best accuracy. Warren
From: John B. Matthews on 29 Jun 2010 13:50
In article <Xns9DA683A562C67WarrensBlatherings(a)81.169.183.62>, Warren <ve3wwg(a)gmail.com> wrote: > One thing that really irks me (in lack of convenience) > is the lack of certain functions in the library support. > For example, I was looking for the inverse of a complex > number function. Did I missed it? My googling didn't > turn up much, nor did grep on the package hdrs. > > So because it is missing (AFIK), I had to google it and > figure out how it is done and code it myself. Wouldn't it > be safer if the function was already provided and tested? > Wouldn't it also be more accurately coded (floating > point can be tricky)? At least it would be tested. > > IIRC, I ran into the similar issues with some other > functions (ATAN2??). The LOG10() issue was > resolved when I discovered there is a base argument > in LOG(), so that was just my own "user error". > > But even if a function is considered "trivial", I > think it would be "safer" to include it. Additionally, > having them provided means that they will > be coded for the best accuracy. So, what is the "missing" function? <http://www.adaic.com/standards/05rm/html/RM-G-1-2.html> -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews> |