Re: Inferring array index type from array object

[Warren <ve3wwg@gmail.com>]

Niklas Holsti expounded in news:88sld2F9m8U1@mid.individual.net:

> 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)? 
...
>>>>> 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